DDD - इकाई बनाने और सत्यापन जिम्मेदारी

Question

मैं अंतिम दिनों में DDD (डोमेन प्रेरित डिजाइन) में रुचि हूँ, लेकिन मैं जो बनाता है और संस्थाओं की पुष्टि करता है की जिम्मेदारियों को समझ नहीं सकता। मैं विभिन्न परिदृश्यों को कवर करने के लिए इस प्रश्न को तोड़ देता हूं।

1. नियमित इकाई (संभावित रूप से मूल्य वस्तु के साथ)। एक उदाहरण के रूप में एक उपयोगकर्ता को ईमेल द्वारा पहचाना जाता है। मेरे पास एक UserFactory है जो डेटा की एक सरणी प्राप्त करता है (संभवतः फॉर्म POST से), और मुझे एक नई उपयोगकर्ता प्रविष्टि वापस कर देता है। क्या कारखाना डेटा की अखंडता को मान्य कर सकता है (उदा: ईमेल के रूप में दिया गया स्ट्रिंग एक वास्तविक ईमेल है, पासवर्ड फ़ील्ड 1 और फ़ील्ड 2 मैच और पासवर्ड में पासवर्ड)? क्या कारखाना मान्य करेगा कि ऐसा कोई उपयोगकर्ता पहले से मौजूद नहीं है (हम दो उपयोगकर्ताओं को एक ही ईमेल के साथ पंजीकृत नहीं करना चाहते हैं)? यदि हां, तो यह मुझे स्वयं या उपयोगकर्ता रेजॉजिटरी का उपयोग करना चाहिए?

2. कुल इकाई। आइए मान लें कि हमारे पास एक पोस्ट इकाई और टिप्पणियां संस्थाएं हैं। मैं पद प्राप्त करने के लिए अपने सभी टिप्पणियों के साथ 12 चाहते हैं, तो मैं जैसे

   कुछ करना $ पोस्ट = $ postRepository-> getById (12);

कैसे प्राप्त करेंबीआईआईडी लागू की जानी चाहिए? इस तरह:

public function getById($id) { 
    $postData = $this->magicFetchFromDB($id); 
    $comments = (new CommentRepository())->getForPost(12); 
    return new PostEntity($postData, $comments); 
} 

या हो सकता है की तरह आलसी के लिए पोस्ट जिम्मेदार अपनी टिप्पणी बनाने, कुछ:

class PostEntity { 
    public function getComments() { 
     if(is_null($this->_comments)) $this->_comments = (new CommentRepository())->getForPost($this->_id); 
     return $this->_comments; 
    } 
} 

? मैं यहां बहुत खो गया हूं और PHP में डीडीडी के उदाहरणों के साथ पर्याप्त जानकारी नहीं है, इसलिए किसी भी मदद की सराहना की जाएगी!

आप एक बहुत, skwee धन्यवाद।

Answer 1

• कारखाना चाहिए केवल संस्थाओं बनाने के बारे में देखभाल। मैं व्यक्तिगत रूप से अपने विचारों और मॉडल परत दोनों में सत्यापन करने के लिए preferr preferr। मैं कुछ आवश्यक क्लाइंट साइड पर सत्यापन (जैसे आवश्यक फ़ील्ड में डेटा की जांच कर रहा है) बनाने के लिए jQuery की सत्यापन प्लगइन जैसी कुछ लाइब्रेरी का उपयोग करूंगा। और फिर मॉडल पर "कट्टर" सत्यापन करें।

  abstract class BaseEntity { 
      public function isValid(); 
  }   
  
  class MyEntity extends BaseEntity { 
      public function isValid() { 
       //actual validation goes here 
      } 
  } 
  

  तुम भी कुछ बुनियादी मान्यता के साथ एक स्थिर सहायक वर्ग का उपयोग कर सकता: मैं यह एक सरल BaseEntity सार वर्ग जो सभी संस्थाओं का विस्तार का उपयोग करना है, और जब से तुम एक उदाहरण के लिए कहा है, यहाँ यह है विधि:

  class ValidationHelper { 
      public static function isValidPhonenumber($value) { 
       //check valid phonenumber, using a regex maybe 
      } 
  
      public static function isAlphanumeric($value) { 
       //check for letters and numbers only 
      } 
  } 
  

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

• जब पहले से ही मौजूदा इकाइयों की जांच करने की बात आती है तो आप यह देखने के लिए अपने डीबी से पूछकर ऐसा कर सकते हैं कि यह देखने के लिए कि इकाई पहले से जोड़ने/अपडेट करने से पहले है या, (इस तरह मैं इसे करना पसंद करता हूं) आप एक जोड़ सकते हैं unique उन कॉलमों के लिए इंडेक्स जिन्हें डीबी में दोहराया नहीं जा सकता है, और उसके बाद कोशिश-पकड़ ब्लॉक में निर्माण या अद्यतन क्वेरी को लपेटें (क्वेरी एक अद्वितीय बाधा उल्लंघन फेंक देगी, यदि दो उपयोगकर्ताओं के उदाहरण के लिए एक ही ई-मेल है) और उसके बाद उचित त्रुटि संदेश

• आपके अंतिम प्रश्न पर यह वरीयता के मामले में आता है। यदि आपके डीबी को 1 मिनट में दस लाख हिट मिलेगी, तो संभवतः अनावश्यक डेटा लाने से बचने के लिए आलसी लोडिंग का उपयोग करना बेहतर होगा। लेकिन यदि आपका डेटाबेस अपेक्षाकृत छोटा है तो आप बहुत अधिक प्रदर्शन को बलि किए बिना उत्सुक लोडिंग का पूरी तरह से उपयोग कर सकते हैं। फिर, यह व्यक्तिगत वरीयता का मामला है।

आशा है कि इस रैंपिंग में से कुछ समझ में आता है, चीयर्स!

Answer 2

इसके लिए सबसे अच्छा और आसान तरीका Doctrine2 का उपयोग करना है। शायद पहले घंटे कठिन हो जाएंगे, लेकिन एक बार जब आप सिद्धांत 2 मास्टर करते हैं तो ऐसे सभी रिश्ते और कुल केक का टुकड़ा होता है।

आप & डीडीडी या डॉक्टरेट 2 के बारे में http://giorgiosironi.blogspot.com/ पर या बस googling के बारे में बहुत सारी जानकारी पा सकते हैं।

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

उन विषयों के बारे में यहां कई अन्य पोस्ट हैं - उपर्युक्त कीवर्ड का उपयोग करने का प्रयास करें।