2013-07-18 11 views
19

देखें client validationdomain level validation करने के लिए आवश्यक होने पर किया जाता है?मॉडल सत्यापन बनाम डोमेन मॉडल सत्यापन

मैं अपने वेब अनुप्रयोगों के लिए ASP.NET MVC का उपयोग करता हूं। मुझे अपने domain models और view models के बीच अंतर करना पसंद है। मेरे डोमेन मॉडल में डेटा होता है जो मेरे डेटाबेस से आता है और मेरे दृश्य मॉडल में मेरे विचार/पृष्ठों पर डेटा होता है।

आइए कहें कि मैं ग्राहक डेटा के साथ काम कर रहा हूं।

मेरे पास Customers नामक मेरे डेटाबेस में एक टेबल होगी।

मैं एक ग्राहक वर्ग जो कुछ इस तरह दिख सकता है:

public class Customer 
{ 
    public int Id { get; set; } 

    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

और मैं एक ही डेटा मैं मेरे विचार पर है कि प्रतिनिधित्व करने के लिए पैदा करेगा ग्राहक दृश्य मॉडल:

[Validator(typeof(CustomerCreateViewModelValidator))] 
public class CustomerCreateViewModel 
{ 
    public string FirstName { get; set; } 

    public string LastName { get; set; } 

    public DateTime DateOfBirth { get; set; } 
} 

@model MyProject.ViewModels.Customers.CustomerCreateViewModel 

@using (Html.BeginForm()) 
{ 
    <table> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.FirstName) 
        @Html.ValidationMessageFor(x => x.FirstName) 
       </td> 
      </tr> 
      <tr> 
       <td> 
        @Html.TextBoxFor(x => x.LastName) 
        @Html.ValidationMessageFor(x => x.LastName) 
       </td> 
      </tr> 
    </table> 

    <button id="SaveButton" type="submit">Save</button> 
} 
:

मैं एक बनाने का विचार है कि मेरी CustomerCreateViewModel स्वीकार करता है और मेरे विचार मॉडल करने के लिए अपने इनपुट फ़ील्ड बांधता होगा

जैसा कि आप देख सकते हैं कि मेरे पास CustomerCreateViewModelValidator है जिसमें मेरे सत्यापन नियम शामिल हैं। उपयोगकर्ता ने टेक्स्ट बॉक्स में कुछ डेटा दर्ज करने के बाद वह सबमिट बटन पर क्लिक करेगा। यदि कुछ फ़ील्ड खाली हैं तो सत्यापन विफल हो जाता है। यदि सभी आवश्यक फ़ील्ड दर्ज किए गए हैं तो सत्यापन सफल हो जाता है। मैं तो इस तरह मेरे डोमेन मॉडल के लिए मेरे विचार मॉडल से डेटा को मैप होगा:

Customer customer = Mapper.Map<Customer>(viewModel); 

इस ग्राहक ने डोमेन मॉडल मैं लेने के लिए और मेरी भंडार स्तर पर इसे पारित और यह मेरी मेज पर डेटा कहते हैं।

डोमेन मॉडल पर सत्यापन कब करने की आवश्यकता है? मैं अपने दृश्य मॉडल पर अपना पूरा सत्यापन करता हूं। मैं डेटाबेस में इसे जोड़ने से पहले अपने डोमेन मॉडल में अपने डेटा को मान्य कर सकता हूं लेकिन यह देखकर कि यह दृश्य मॉडल पर मान्य था, क्या यह क्लाइंट पक्ष पर एक ही सत्यापन की प्रतिलिपि नहीं करेगा?

क्या कोई इस सत्यापन मामले पर कुछ प्रकाश साझा कर सकता है?

+0

क्या आपके पास परतों के बीच अलग सत्यापन नियम हैं? इसका मतलब है, क्या यूआई में कुछ वैध होना संभव है जिसे डोमेन में मान्य नहीं माना जाता है? –

+0

इस समय दोनों एक जैसा होना चाहिए। मैं मान्यताओं के बारे में सामान्यीकरण कर रहा हूं, न केवल मेरी परियोजनाओं के लिए विशिष्ट। –

+1

हालांकि होगा कि डीडीडी प्रत्येक डोमेन ऑब्जेक्ट पर 'मान्य()' इंस्टेंस विधि की ओर झुक जाएगा जो स्वयं को मान्य करता है। हालांकि मैं एक डीडीडी विशेषज्ञ से दूर हूं। एक दिलचस्प सवाल के लिए +1। –

उत्तर

9

हमेशा दोनों स्तरों पर मान्य करें।

आपको दृश्य मॉडल को सत्यापित करने की आवश्यकता है क्योंकि यदि आप कुछ गलत कर चुके हैं तो आप जितनी जल्दी संभव हो सके उपयोगकर्ता को तुरंत और आसानी से फ़ीड करना चाहते हैं। यदि मॉडल अमान्य है तो आप अपने शेष डोमेन तर्क को परेशान नहीं करना चाहते हैं।

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

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

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

0

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

+0

तो आप कह रहे हैं कि यदि आपके पास केवल 1 एप्लिकेशन है जो आपके डेटाबेस का उपयोग करता है तो दृश्य मॉडल पर सत्यापन पर्याप्त है? –

+1

मैं क्या कह रहा हूं कि यदि आप केवल एक क्लाइंट से अपनी रिपॉजिटरी का उपयोग करते हैं तो स्पष्ट रूप से व्यूमोडेल पर सत्यापन पर्याप्त होगा क्योंकि केवल आपके नियंत्रकों के माध्यम से, रजिस्ट्रेशन को पाने के अन्य तरीके नहीं होंगे, जो सत्यापन तर्क –

+2

को प्रेरित करते हैं एक एनीमिक डोमेन मॉडल के लिए। आपके डोमेन मॉडल को इसके आविष्कारों की रक्षा करने की आवश्यकता है। – JefClaes

2

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

डोमेन स्तर पर, आपको व्यवसाय डोमेन नियमों की जांच करनी चाहिए। उदाहरण के लिए, यदि उपयोगकर्ता किसी नए उत्पाद के बारे में विवरण दर्ज कर रहा है, तो क्या उत्पाद का नाम पहले से मौजूद है? या हो सकता है कि उस उपयोगकर्ता के कौशल के आधार पर, किसी नए उपयोगकर्ता को कॉन्फ़िगर करते समय उपयोगकर्ता ने एक वैध विभाग का चयन किया हो? यह सिर्फ हवा के उदाहरणों से बाहर है, लेकिन मुझे आशा है कि वे मेरे विचार का एक विचार दें।

6

एक सामान्य नियम के रूप में मैं डोमेन मॉडल को सबसे महत्वपूर्ण कोड मानता हूं और इसलिए अपने राज्य के पवित्र प्रबंधन का प्रबंधन करता हूं।इसी कारण से मैं कभी भी डोमेन मॉडल को मान्य स्थिति में नहीं मानूंगा क्योंकि यह एक प्रस्तुति परत द्वारा संचालित किया गया था जिसे वैधता लागू करने के लिए माना जाता है। इसका मतलब यह होगा कि आपकी डोमेन परत कड़ाई से आपकी प्रस्तुति परत के साथ मिलकर है।

डोमेन मॉडल से बाहर सोचना शुरू करना सबसे अच्छा है (onion architecture)। इन सबके पीछे तर्क यह है कि डोमेन मॉडल समय के साथ बदलने की संभावना कम है और एक आवेदन के लिए कोर के रूप में कार्य करता है, जो परतों को एक-दूसरे की खामियों से इन्सुलेट करता है।

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

मैंने कोड बेस देखे हैं जिसमें केवल डोमेन परत सत्यापन और कोडबेस को संभाला गया है जिसमें दोनों डोमेन- और प्रस्तुति परत में सत्यापन को संभाला गया था। मुझे इस बिंदु पर सत्यापन तर्क को डुप्लिकेट करने की प्राथमिकता है, क्योंकि मैंने देखा है कि डोमेन सत्यापन त्रुटियों को अर्थपूर्ण रूप से प्रासंगिक उपयोगकर्ता-इंटरफ़ेस में मैप करना कितना मुश्किल है।

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