वसंत डीटीओ-डीएओ (संसाधन - इकाई) मैपिंग किस अनुप्रयोग परत में है: नियंत्रक या सेवा?

Question

मैं एक स्प्रिंग (4.1.7) वेब एप्लिकेशन लिख रहा हूं जो एक सतत सेवा का खुलासा करता है और मेरी दृढ़ता संस्थाओं का पर्दाफाश करने के बजाय नियंत्रक और क्लाइंट ब्राउज़र के बीच संचार के लिए डीटीओ "संसाधन" ऑब्जेक्ट्स का उपयोग करना चाहता है।

वर्तमान में एप्लिकेशन के पास निम्न परतें हैं:

• देखें (JSP/JSON)
• नियंत्रक (रों)
• डीएओ (@Service)
• डीएओ (@Repository)

मेरा सवाल यह है कि, मुझे डीटीओ संसाधनों में अपनी डीएओ इकाइयों को मैपिंग क्यों करनी चाहिए? मैंने Spring HATEOAS का उपयोग करके कुछ उदाहरणों पर एक नज़र डाली और Controller में मैप किए जाने वाले वस्तुओं को दिखाते हुए Resource दिखाएं। क्या यह करने का सबसे अच्छा तरीका है, या क्या मुझे डीएओ सेवा से संसाधन वापस कर रहे हैं?

मैं (स्वयं और संबंधित संसाधन के लिए) लौटे संसाधन को Link तत्वों जोड़ना चाहते हैं, लेकिन नहीं देख सकते हैं कि Link तत्वों अगर यह Controller का ज्ञान होने और यह @RequestMapping है बिना Service में संसाधित का समाधान किया जाएगा। दूसरी ओर, मुझे नहीं पता कि मैपिंग के साथ Controller को अव्यवस्थित करना अच्छा अभ्यास है या नहीं।

Answer 1

डीटीओ (डेटा ट्रांसफर ऑब्जेक्ट) इसके नाम पर ओबविउस के रूप में, आपके आवेदन के डेटा को स्थानांतरित करने के लिए उपयोग किया जाता है। आपके मामले में उन्हें रखने के लिए सबसे अच्छी जगह आपके नियंत्रक परत में है। आपको केवल डीटीओ को यूआई में बेनकाब करना चाहिए और जब आपको यूआई से डेटा प्राप्त होता है तो आपको इसे व्यापार इकाई में परिवर्तित करना चाहिए और नीचे के स्तर को कॉल करना चाहिए। कारण यह है कि, इस तरह आप यूआई तोड़ने के बिना व्यवसाय की शुरुआत को बदलने के लिए स्वतंत्र हैं और बेहतर रखरखाव की ओर ले जाते हैं। आपके व्यवसाय/दाओ टियर को भी इसी कारण से यूआई और डीटीओ से अनजान होना चाहिए। तो डीटीओ को बुसनेस इकाइयों में परिवर्तित करने के लिए सबसे अच्छी जगह और आपके ऐप में इसके विपरीत कंट्रोलर टियर है।

पुनश्च: Dozer भी पर एक नजर डालें;)

Answer 2

जहां मैं अपने डीएओ संस्थाओं डीटीओ संसाधनों से मैप किया जाना चाहिए?

सेवा परत में। आम तौर पर सेवा परत लागू मामलों का उपयोग करता है और लेनदेन सीमा है।

उदा।

@Transactional 
public OrderPlacedTO placeOrder(ShoppingCartTO cart)[ 
    OrderDao orderDao = ... 
    // implement your use case here 
    ... 
} 

मैं (स्वयं और संबंधित संसाधन के लिए) लौटे संसाधन के लिए लिंक तत्व जोड़ना चाहते हैं, लेकिन यह नियंत्रक के ज्ञान के बिना नहीं देख सकते हैं कि लिंक तत्वों यदि सेवा में संसाधित का समाधान किया जाएगा और यह @RequestMapping

आप सही हैं। ये जानकारी केवल नियंत्रक में उपलब्ध है। आप एक सामान्य यूई मॉडल की तरह एक संसाधन मॉडल जोड़ सकते हैं।

उदा।

public class OrderPlacedRessource extends ResourceSupport { 

    private Long oderNumber; 

    public void setOrderNumber(Long orderNumber){ this.orderNumber = orderNumber; } 
    public Long getOrderNumber() { return this.orderNumber } 
} 

और अपने नियंत्रक में आप तो इसका इस्तेमाल और जोड़ सकते हैं लिंक

@RequestMapping("/placeOrder") 
public @ResponseBody OrderPlacedRessource placeOrderAction(HttpServletRequest request){ 
    OrderService service = ...; 
    ShoppingCartTO cart = ...; 

    OrderPlacedTO orderPlacedTO = service.placeOrder(cart); 
    OrderPlacedRessource orderPlacedRes = new OrderPlacedModel(); 

    orderPlacedRes.setOrderNumber(orderPlacedTO.getOrderNumber()); 

    // since orderPlacedRes is a RessourceSupport we can add links 
    // Use the HttpServletRequest to build your links 
    Link link = new Link("http://localhost:8080/something"); 
    orderPlacedRes.addLink(link); 

    return orderPlacedRes; 
} 

पुनश्च: बिल्डिंग लिंक यदि आप एक org.springframework.hateoas.mvc.ControllerLinkBuilder का उपयोग आसान है। E.g

orderPlacedRes.add(linkTo(methodOn(YourController.class).orderOverview(userId)).withSelfRel()); 

विवरण के लिए Building a Hypermedia-Driven RESTful Web Service देखें।

Answer 3

आप मैपिंग कहां से कहां से विभिन्न दृष्टिकोण को पूरा कर सकते हैं। उदाहरण के लिए इस ट्यूटोरियल को देखें: http://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application या प्रश्न: http://forum.spring.io/forum/other-spring-related/architecture/56753-controller-vs-service-vs-private-method-on-command-object। यह भी आपके नियंत्रकों में कितने तर्क पर निर्भर करता है। मैं प्रैक्टिस < -> उपयोग कक्षाओं में डीटीओ मैपिंग करना पसंद करता हूं। और आप अपेक्षाकृत स्वतंत्र हैं, जहां से आप उन्हें बुलाते हैं। ऐसा लगता है कि, "सबसे अच्छा डिजाइन सबसे सरल डिजाइन है जो काम करता है" - आइंस्टीन। डीटीओ की आवश्यकता के बारे में इसी तरह का आलेख: Should services always return DTOs, or can they also return domain models?

Answer 4

मेरी राय नियंत्रक परत में मैपिंग करना है क्योंकि यह परत इनपुट/आउटपुट के लिए ज़िम्मेदार है। सेवा परत स्वतंत्र होना चाहिए ताकि इसका उपयोग एक और इंटरफ़ेस विकसित करने के लिए किया जा सके।

यदि आप मैपर कक्षाएं बनाते हैं और केवल उन्हें अपने नियंत्रक परत में नियंत्रक में ज्यादा अव्यवस्था नहीं होती है।