क्या मुझे एक पीओसीओ में सत्यापन तर्क रखना चाहिए?

Question

चलो कहते हैं कि मैं बहुत की तरह एक POCO करते हैं:

public class Name 
{ 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
} 

प्रथम नाम और अंतिम नाम रिक्त नहीं हो सकता है। मैं इस तरह एक विधि में जोड़ना चाहिए:

public List<Error> Validate() 
{ 
    var errors = new List<Error>(); 

    if (String.IsNullOrEmpty(FirstName)) 
     errors.Add(new Error("FirstName", "You must fill out first name.")); 
    if (String.IsNullOrEmpty(LastName)) 
     errors.Add(new Error("LastName", "You must fill out last name.")); 
} 

जहां Error एक struct है कि एक NameValueDictionary होता है। क्या यह चीजों को करने का एक अच्छा तरीका है? मैं संभावित रूप से भंडार के साथ एक समस्या देख सकता हूं जहां कोई व्यक्ति इस पीओसीओ को Validate() के माध्यम से इसे चलाने के बिना सहेजने का प्रयास करता है।

Answer 1

xVal जैसे पहलू-उन्मुख सत्यापन फ्रेमवर्क का उपयोग करने पर विचार करें।

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

public class Name 
{ 
    [Required] 
    public string FirstName { get; set; } 
    [Required] 
    public string LastName { get; set; } 
} 

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

Answer 2

मैं नहीं करूँगा। मेरे पीओसीओ के पास उनके संदर्भ के आधार पर अलग-अलग सत्यापन हैं। "मेरे व्यक्ति वस्तुओं को इस एप्लिकेशन में एक पता होना चाहिए, लेकिन उन्हें केवल इस अन्य एप्लिकेशन में एक फोन नंबर होना चाहिए" ... वह चीज है जिस पर आप नजर रखना चाहते हैं और इसके लिए लचीला होना चाहते हैं।

मैं एनीमिक डोमेन मॉडल का वकील हूं क्योंकि मैं आम तौर पर उसी डोमेन का पुन: उपयोग करता हूं, लेकिन संदर्भ के आधार पर अलग-अलग व्यवहार और सत्यापन निर्दिष्ट करता हूं (जो एक ही एप्लिकेशन के विभिन्न क्षेत्र भी हो सकता है)।

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

Answer 3

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

आपके नमूने में नियम सरल हैं, लेकिन आपको अक्सर अधिक जटिल नियम लिखने की आवश्यकता होगी। आपको शायद Csla.Net ढांचे की जांच करनी चाहिए।