नियमों के रूप में व्यवसाय तर्क के साथ एनीमिक डोमेन मॉडल से कैसे बचें

Question

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

उदाहरण के लिए, वस्तु है:

class Employee { 
private string Name; 
private float Salary; 
private float PensionPot; 
private bool _pension; 
private bool _eligibleForPension; 

} 

मैं जैसे नियमों का निर्माण करने की जरूरत है "अगर वेतन 100,000 से अधिक है और _eligibleForPension है झूठी तो _eligibleForPension सेट के रूप में सच" और "अगर _pension तो सच है _eliableForPension को सत्य के रूप में सेट करें "।

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

दूसरी चिंता यह है कि वास्तविक कर्मचारी डीबी को समर्थित इकाई फ्रेमवर्क इकाइयां हैं, इसलिए मुझे इन "संस्थाओं" में तर्क जोड़ने में खुशी नहीं है - खासकर जब मुझे प्रत्येक नियम इकाई परीक्षण के लिए ऑब्जेक्ट्स का नकल करने की आवश्यकता होती है। मैं उन पर नकल कैसे कर सकता हूं यदि उनके पास नियम हैं जो मैं एक ही वस्तु पर परीक्षण कर रहा हूं?

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

Answer 1

एक दृष्टिकोण नियमों को Employee के आंतरिक वर्ग बनाना है। इस दृष्टिकोण का लाभ यह है कि खेत निजी रह सकते हैं। इसके अलावा, नियमों के आह्वान के कर्मचारी वर्ग अपने आप में लागू किया जा सकता है, यह सुनिश्चित करना है कि वे हमेशा जब जरूरत लागू कर रहे हैं:

class Employee 
{ 
    string id; 
    string name; 
    float salary; 
    float pensionPot; 
    bool pension; 
    bool eligibleForPension; 

    public void ChangeSalary(float salary) 
    { 
     this.salary = salary; 
     ApplyRules(); 
    } 

    public void MakeEligibleForPension() 
    { 
     this.eligibleForPension = true; 
     ApplyRules(); // may or may not be needed 
    } 

    void ApplyRules() 
    { 
     rules.ForEach(rule => rule.Apply(this)); 
    } 

    readonly static List<IEmployeeRule> rules; 

    static Employee() 
    { 
     rules = new List<IEmployeeRule> 
     { 
      new SalaryBasedPensionEligibilityRule() 
     }; 
    } 

    interface IEmployeeRule 
    { 
     void Apply(Employee employee); 
    } 

    class SalaryBasedPensionEligibilityRule : IEmployeeRule 
    { 
     public void Apply(Employee employee) 
     { 
      if (employee.salary > 100000 && !employee.eligibleForPension) 
      { 
       employee.MakeEligibleForPension(); 
      } 
     } 
    } 
} 

एक समस्या यह यहां कर्मचारी वर्ग सभी नियम कार्यान्वयन को रोकने के लिए किया है। यह एक बड़ी समस्या नहीं है क्योंकि नियम कर्मचारी पेंशन से जुड़े व्यवसाय तर्क को जोड़ते हैं और इसलिए वे एक साथ हैं।

Answer 2

व्यवसाय नियम आमतौर पर एक दिलचस्प विषय होते हैं। निश्चित रूप से एक समग्र/इकाई invariant और एक व्यापार नियम के बीच एक अंतर हो सकता है। व्यवसाय नियमों को बाहरी डेटा की आवश्यकता हो सकती है और मैं एक समग्र/इकाई को बदलने वाले नियम से सहमत नहीं हूं।

आपको नियमों के लिए विनिर्देश पैटर्न को सोचना चाहिए। नियम मूल रूप से वापस लौटना चाहिए चाहे वह टूटा हुआ हो या संभवतः एक प्रकार का वर्णन न हो।

अपने उदाहरण SalaryBasedPensionEligibilityRule में, जैसा कि eulerfx द्वारा प्रयोग किया जाता है, कुछ PensionThreshold पड़ सकता है। यह नियम वास्तव में एक कार्य की तरह दिखता है क्योंकि नियम वास्तव में इकाई की किसी भी वैधता की जांच नहीं कर रहा है।

तो मैं सुझाव दूंगा कि नियम एक निर्णय तंत्र हैं और कार्य राज्य को बदलने के लिए हैं।

कहा जा रहा है कि आप शायद यहाँ सलाह के लिए इकाई पूछने के लिए जब से तुम राज्य का पर्दाफाश करने के लिए नहीं चाहते हो सकता है चाहता हूँ:

public class Employee 
{ 
    float salary; 
    bool eligibleForPension; 

    public bool QualifiesForPension(float pensionThreshold) 
    { 
     return salary > pensionThreshold && !eligibleForPension; 
    } 

    public void MakeEligibleForPension() 
    { 
     eligibleForPension = true; 
    } 
} 

यह आदेश/क्वेरी जुदाई विचार के साथ चिपक जाता है।

आप अपने ORM वस्तुओं से सीधे निर्माण कर रहे हैं और नहीं करना चाहते हैं, या नहीं कर सकते हैं, शामिल सभी व्यवहार तो यह ठीक है --- लेकिन यह निश्चित रूप से मदद मिलेगी :)