डोमेन मॉडल

Question

एएसपी.नेट एमवीसी प्रोजेक्ट में हम संपादन मॉडल/पोस्टमोडेल को कैसे परिवर्तित करें हम डोमेन मॉडल से देखने के लिए ऑटोमैपर का उपयोग कर रहे हैं - और कभी-कभी ऐसा करने के दौरान पदानुक्रम को भी फ़्लैट करना। यह एक आकर्षण की तरह काम करता है और हमारे विचारों के प्रतिपादन तर्क को बहुत दुबला और सरल बनाता है।

भ्रम शुरू होता है जब हम डोमेन मॉडल के लिए viewmodel (या postmodel या editmodel) से अन्य रास्ते जाने के लिए, खासकर जब अद्यतन करने वस्तुओं चाहते हैं। हम स्वचालित नहीं कर सकते का उपयोग/दो तरह मानचित्रण है क्योंकि:

1. हम चपटा पदानुक्रम
2. डोमेन मॉडल पर सभी गुण unflat को परिवर्तनशील होना चाहिए था होता/सार्वजनिक setters
3. परिवर्तन दृश्य से आने से हमेशा डोमेन पर वापस मैप किए जाने वाले फ्लैट गुण नहीं होते हैं, लेकिन कभी-कभी "ChangeManagerForEmployee()" या इसी प्रकार की विधियों को कॉल करने की आवश्यकता होती है।

यह भी जिमी Bogards लेख में वर्णित है: The case for two-way mapping in AutoMapper, लेकिन इस का हल विस्तार से वर्णन किया नहीं है, केवल कि वे जाना:

EditModel से CommandMessages के लिए - loosely- से जा रहा संपादित मॉड्यूल दृढ़ता से टाइप किए गए संदेशों को तोड़ने के लिए टाइप किया गया। एक एकल संपादन मॉडल आधा दर्जन संदेश उत्पन्न कर सकता है।

एक समान SO question में Mark Seeman द्वारा एक जवाब है, जहां वह उल्लेख है कि वहाँ

हम सार मानचित्रकारों और सेवाओं का उपयोग एक डोमेन वस्तु

लेकिन विवरण के लिए एक PostModel मैप करने के लिए - वैचारिक और तकनीकी कार्यान्वयन - छोड़ दिया गया है।

हमारे विचार अभी के लिए है:

1. प्राप्त नियंत्रक की कार्रवाई विधि में एक FormCollection
2. मूल डोमेन मॉडल प्राप्त करें और viewModelOriginal और viewModelUpdated
3. viewModelUpdated UpdateModel() का उपयोग करते हुए FormCollection विलय करने के लिए इसे समतल
4. viewModelOriginal की तुलना करने के लिए कुछ सामान्य सहायक विधि का उपयोग करें ViewModelUpdated
5. या तो ए) उत्पन्न करें CommandMessages एक ला जिमी Bogard या बी) गुण और विधियों (शायद सीधे AutoMapper के माध्यम से) 1-1 गुण मानचित्रण के माध्यम से डोमेन मॉडल में सीधे मतभेद Mutate

कोई कैसे वे के माध्यम से FormCollection से आते हैं के कुछ उदाहरण प्रदान कर सकते हैं डोमेन मॉडल में editmodel/postmodel? "कमांड मैसेज" या "अमूर्त मैपर और सेवाएं"?(- मुझे लगता है कि इस अवधारणा को आप अनदेखा कर रहे थे हो सकता है कमान क्वेरी जिम्मेदारी पृथक्करण), संभवतः भी घटना सोर्सिंग के साथ

[HttpPost] 
public ActionResult Update(UpdateProductViewModel viewModel) 
{ 
    // fetch the domain model that we want to update 
    Product product = repository.Get(viewModel.Id); 

    // Use AutoMapper to update only the properties of this domain model 
    // that are also part of the view model and leave the other properties unchanged 
    AutoMapper.Map<UpdateProductViewModel, Product>(viewModel, product); 

    // Pass the domain model with updated properties to the DAL 
    repository.Update(product); 

    return RedirectToAction("Success"); 
} 

Answer 1

मैं निम्नलिखित पैटर्न का उपयोग करें।

यह मूल रूप से डेटा स्रोत से पढ़ने और डेटा स्रोत पर लिखने के तर्क को अलग करने का एक अभ्यास है, इसका अर्थ यह भी हो सकता है कि पढ़ने और लिखने के लिए अलग-अलग डेटा मॉडल हो।

यह एक अच्छी जगह शुरू करने के लिए हो सकता है: http://abdullin.com/cqrs/

Answer 2

आप CQRS विचार करना चाह सकते:

Answer 3

विकल्प C: यह सब नियंत्रक कार्रवाई में रख दें। अगला, अगर वह बालों वाली हो जाती है, सेवाओं (अमूर्त मैपर) या संदेश-जैसी-विधियों (कमांड संदेश मार्ग) में विघटित हो जाती है।

कमान संदेश रास्ता:

public ActionResult Save(FooSaveModel model) { 
    MessageBroker.Process(model); 

    return RedirectToAction("List"); 
} 

और प्रोसेसर:

public class FooSaveModelProcessor : IMessageHandler<FooSaveModel> { 

    public void Process(FooSaveModel message) { 
     // Message handling logic here 
    } 

} 

यह वास्तव में है बस नियंत्रक कार्रवाई से बाहर है और अलग-अलग, विशेष संचालकों में फार्म की "संसाधन" जाने के बारे में ।

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

Answer 4

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

मेरी बचत अजाक्स को एमवीसी एक्शन में जेएसओएन के रूप में पोस्ट किया गया है और यह क्रियाएं एमवीसी द्वारा दृश्य मॉडल संरचना में जादुई रूप से बंधी हुई हैं। मैं फिर शीर्ष स्तर दृश्य मॉडल और उसके वंशजों को इसके समकक्ष डोमेन संरचना में बदलने के लिए ऑटोमैपर का उपयोग करता हूं। मैंने उन मामलों के लिए कई कस्टम ऑटोमैपर आईटीइप कन्वर्टर्स को परिभाषित किया है जहां क्लाइंट पर एक नया बच्चा आइटम जोड़ा गया है (मैं Knockout.js का उपयोग कर रहा हूं) और मुझे एक स्पष्ट सेवा विधि कॉल करने की आवश्यकता है। कुछ की तरह:

  foreach (ChildViewModel childVM in viewModel.Children) 
     { 
      ChildDomainObject childDO = domainObject.Children.Where(cdo => cdo.ID.Equals(childVM.ID))).SingleOrDefault(); 
      if (childDO != null) 
      { 
       Mapper.Map<ChildViewModel, ChildDomainObject>(childVM, childDO); 
      } 
      else 
      { 
       MyService.CreateChildDO(someData, domainObject); // Supplying parent 
      } 
     } 

मैं हटाता के लिए एक समान बात है और इस प्रक्रिया cascades काफी अच्छी तरह से पूरी संरचना के माध्यम से नीचे है। मुझे लगता है कि एक चपटा हुआ संरचना या तो काम करना आसान हो सकता है या कठिन हो सकता है - मेरे पास एक आईडी के साथ एक सारडोमेन व्यूमोडेल है जिसके साथ मैं उपरोक्त मिलान करता हूं, जो मदद करता है।

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