स्प्रिंग एमवीसी 3 - एक फॉर्म के लिए 'अपरिवर्तनीय' ऑब्जेक्ट को बाध्यकारी

मेरे पास कई अपरिवर्तनीय आविष्कार और अखंडता जांच के साथ कई अच्छी तरह से यूनिट-परीक्षण और बारीकी से समृद्ध डीडीडी मॉडल कक्षाएं हैं। ऑब्जेक्ट का त्वरण पर्याप्त रचनाकारों, स्थैतिक फैक्ट्री विधियों और यहां तक कि बिल्डर्स के माध्यम से होता है।स्प्रिंग एमवीसी 3 - एक फॉर्म के लिए 'अपरिवर्तनीय' ऑब्जेक्ट को बाध्यकारी

अब, मुझे कुछ कक्षाओं के नए उदाहरण बनाने के लिए एक स्प्रिंग एमवीसी फॉर्म प्रदान करना होगा।

ऐसा लगता है कि (मैं एक विशेषज्ञ नहीं हूं) कि मुझे सभी प्रकार के बैकिंग कक्षाओं के लिए खाली कन्स्ट्रक्टर और विशेषता के सेटर्स प्रदान करना है जिन्हें मैं बांधना चाहता हूं।

तो, मुझे क्या करना चाहिए?

उपयुक्त विधियों/निर्माता को बुलाकर मेरे डोमेन मॉडल (डीआरवाई सिद्धांत के लिए बहुत कुछ ...) को सूचनाओं का समर्थन और हस्तांतरण करने के लिए समर्पित एनीमिक ऑब्जेक्ट बनाएं?

या क्या कोई ऐसा मैकेनिज्म है जो मुझे याद आया जो मेरा दिन बचा सकता है? :)

आपके ज्ञान के लिए अग्रिम धन्यवाद!

स्रोत

2011-10-13 M' λ'

हां आपको सभी इनपुट लेने के लिए फॉर्म के लिए ऑब्जेक्ट्स बनाने की आवश्यकता होगी, और एक ही ऑपरेशन में इस ऑब्जेक्ट के साथ अपना मॉडल अपडेट करें।

लेकिन मैं इस ऑब्जेक्ट को एनीमिक नहीं कहूंगा (विशेष रूप से यदि आप डीडीडी करते हैं)। यह वस्तुएं काम की एक इकाई का प्रतिनिधित्व करती हैं। तो यह डोमेन अवधारणा भी हैं!

स्रोत

2011-10-13 13:22:12 Ralph

प्रस्तुति परतों के साथ बाध्यकारी के लिए उपयोग की जाने वाली वस्तुओं को सामान्य रूप से दृश्य मॉडल कहा जाता है और वे DTOs डोमेन ऑब्जेक्ट्स से मैप किए गए डेटा को प्रदर्शित करने और फिर डोमेन ऑब्जेक्ट्स पर उपयोगकर्ता इनपुट मैप करने की दिशा में लक्षित होते हैं। डोमेन वस्तुओं से

डाटा चपटा किया जा सकता है या अन्यथा किसी विशेष दृश्य के की आवश्यकताओं को फिट करने के लिए बदल: मॉडल देखें आम तौर पर बहुत डोमेन वस्तुओं वे प्रतिनिधित्व करते हैं, हालांकि कुछ महत्वपूर्ण अंतर हैं के समान दिखाई। एमवीसी जैसे प्रेजेंटेशन फ्रेमवर्क में मैपिंग की तुलना में मैपिंग सादे ऑब्जेक्ट्स में होना आसान है। डीबग करना और त्रुटियों का पता लगाना आसान है।
किसी दिए गए दृश्य को एकाधिक डोमेन ऑब्जेक्ट्स से डेटा की आवश्यकता हो सकती है - एक डोमेन ऑब्जेक्ट नहीं हो सकता है जो दृश्य की आवश्यकताओं को फिट करता है। एक दृश्य मॉडल एकाधिक डोमेन ऑब्जेक्ट्स द्वारा पॉप्युलेट किया जा सकता है।
एक दृश्य मॉडल सामान्य रूप से एक विशिष्ट प्रस्तुति ढांचे के साथ दिमाग में डिज़ाइन किया गया है और इस तरह बाध्यकारी और क्लाइंट साइड सत्यापन के लिए ढांचे के विशिष्ट विशेषताओं का उपयोग कर सकते हैं। जैसा कि आपने कहा है, एक सामान्य आवश्यकता पैरामीटर रहित कन्स्ट्रक्टर के लिए है, जो एक दृश्य मॉडल के लिए ठीक है। फिर, किसी जटिल प्रकार के जटिल मैपिंग तंत्र की तुलना में दृश्य मॉडल का परीक्षण और प्रबंधन करना बहुत आसान है।

मॉडल देखें सूखी सिद्धांत का उल्लंघन करता है, करीब से देखने मॉडल की जिम्मेदारी देखो हालांकि बाद दिखाई देते हैं अलग तो साथ single responsibility principle मन में यह उचित है दो वर्गों के लिए है। इसके अलावा, this पर एक नज़र डालें, जो पुन: उपयोग की फॉरेसी पर अक्सर चर्चा करता है, अक्सर डीआरवाई सिद्धांत का नेतृत्व करता है।

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

नोट भी, पुस्तकालय हैं जो दृश्य मॉडल और डोमेन ऑब्जेक्ट्स के बीच मैपिंग को सरल बनाने का प्रयास करते हैं, उदाहरण के लिए .NET Framework के लिए AutoMapper।

स्रोत

2011-10-13 21:15:03 eulerfx

जबकि मुझे DRY के बारे में बहुत अधिक परवाह नहीं है, मुझे अनावश्यक परतों को भी पसंद नहीं है, और यह अच्छा होगा अगर मैं डोमेन इकाई से जुड़ सकता हूं जब इकाई दृश्य संरचना जैसा दिखता है। यहां तक कि मामूली जटिल परिदृश्यों के लिए, दृश्य इकाइयों को डोमेन इकाइयों से अलग करना अच्छा होता है, लेकिन डोमेन में उपलब्ध एक बहुत ही सरल नाम इकाई के साथ बहुत सरल परिदृश्य ("firstName", "middleName", "lastName" के लिए) मॉडल क्लास बस अपर्याप्त व्यस्त कार्य/बॉयलरप्लेट की तरह दिखता है। अफसोस की बात है, मुझे ज्यादा विकल्प नहीं दिख रहा है। –

मैं एक डीटीओ इंटरफेस बनाने के द्वारा इस हल:

public interface DTO<T> { 
    T getDomainObject(); 

    void loadFromDomainObject(T domainObject); 
} 

public class PersonDTO implements DTO<Person> { 
    private String firstName; 
    private String lastName; 

    public PersonDTO() { 
     super(); 
    } 

    // setters, getters ... 

    @Override 
    public Person getDomainObject() { 
     return new Person(firstName, lastName); 
    } 

    @Override 
    public void loadFromDomainObject(Person person) { 
     this.firstName = person.getFirstName(); 
     this.lastName = person.getLastName(); 
    } 

    // validation methods, view formatting methods, etc 
}

यह भी डोमेन मॉडल में लीक से देखने सत्यापन और स्वरूपण सामान बंद हो जाता है। मैं वास्तव में अपने डोमेन ऑब्जेक्ट्स में स्प्रिंग विशिष्ट (या अन्य ढांचे विशिष्ट) एनोटेशन (@ वैल्यू, आदि) और javax.validation एनोटेशन होने से नापसंद करता हूं।

स्रोत

2013-09-19 18:14:19

स्प्रिंग एमवीसी 3 - एक फॉर्म के लिए 'अपरिवर्तनीय' ऑब्जेक्ट को बाध्यकारी

उत्तर

संबंधित मुद्दे