क्या डोमेन इकाई के उत्परिवर्तनीय गुणों को मूल्य वस्तु के रूप में संग्रहीत करना ठीक है?

Question

मेरे उपयोगकर्ता एंटीटी के कुछ हिस्सों हैं जो मैं बदलने और पास करने में सक्षम होना चाहता हूं, और कुछ हिस्सों को स्थिर रहना चाहिए।

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

इसका एक उदाहरण उपयोगकर्ताEntity बनाते समय होगा। चूंकि UserEntity किसी आईडी के बिना मौजूद नहीं हो सकता है, इसलिए मेरा नियंत्रक UserData ऑब्जेक्ट बना सकता है जो UserEntity गुणों को मानकीकृत करेगा। मैपर डीबी में एक इकाई बनाता है, यह एक नई UserEntity बना देगा और कन्स्ट्रक्टर में आईडी और UserData ऑब्जेक्ट में पास होगा।

जब उपयोगकर्ता एन्टीटी को ईमेल या पासवर्ड जैसी जानकारी की आवश्यकता होती है, तो यह केवल इसके उपयोगकर्ता डेटा को देख सकता है।

अधिक पोर्टेबल लगता है, लेकिन यह ओवरकिल है? क्या कोई बेहतर समाधान है?

नोट

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

• "मानकीकृत" से मेरा मतलब है कि मेरी जानकारी एक समान होने की आवश्यकता है, जहां भी यह मौजूद है। उदाहरण के लिए, email हमेशा n लंबाई और वैध प्रारूप में होने की आवश्यकता है, name हमेशा n लंबाई, आदि होना आवश्यक है। मेरा लक्ष्य यह है कि मैं उन "नियमों" को एक ही स्थान पर सेट करने में सक्षम होना चाहता हूं .. .और चूंकि UserEntity (mutable वाले) के इन गुणों को इकाई के बाहर मौजूद है, कभी-कभी, वे संभावित रूप से अपने स्वयं के मूल्य वस्तु में स्वयं ही रह सकते हैं।

Answer 1

मुझे नहीं लगता कि वहाँ है "एक सच्चा रास्ता" यह (कोई बात नहीं आप इसके बारे में क्या पढ़ा) करने के लिए ... अगर यह अपने मॉडल में समझ में आता है, तो यह अच्छा मेरे लिए लग रहा है। मुझे यकीन नहीं है कि जब आप कहते हैं कि "उनमें से कई क्षेत्रों को मानकीकृत करने की आवश्यकता है" और यह क्यों नहीं है कि यह UserEntity के हिस्से के रूप में क्यों किया जा सकता है, लेकिन जो भी हो। उस ने कहा, बाधाएं आप पूरी तरह से अलग वस्तु वर्ग के बिना जो करने की कोशिश कर रहे हैं उसे पूरा कर सकते हैं।

टिप्पणियाँ/आलोचक:

क्या आप वास्तव में एक सख्त "वस्तु" मॉडल के साथ जाने नहीं करता है सुझाव दे रहे हैं यानी UserData सिर्फ चीजें हैं जो वास्तव में UserEntity की विशेषताओं से बना है, और कोई अन्य है उन विशेषताओं के लिए अंतर्निहित संबंध।

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

<? 
// assume an appropriately defined UserEntity class... 

// I'm using stdClass just to keep the parameters together to pass all at once 
// I'm assuming some basic user data passed from the browser 
$user_data = (object) array(
    'email' => $_REQUEST['email'], 
    'name' => $_REQUEST['name'], 
    'password' => $_REQUEST['password'], 
    'confirm_password' => $_REQUEST['confirm_password'] 
); 

/* 
validateData is static so it can be called before you create the new user 
It takes the $user_data object to validate and, if necessary, modify fields. 
It also takes a $create flag which indicates whether the data should be 
checked to make sure all of the necessary fields are there to create the user 
with. This allows you to call it on update with the $create flag unset and it 
will pass validation even if it's missing otherwise required fields. 
It returns $result, which indicates pass or failure, and the potentially modified 
$user_data object 
*/ 
$create = TRUE; 
list($result, $user_data) = UserEntity::validateData($user_data, $create); 

// equivalence allows you to pass back descriptive error messages 
if ($result === TRUE) { 
    // create the user in the database, get back $user_id... 
    $user = new UserEntity($user_id, $user_data); 
} 
else { 
    // return error to user 
} 

// access user data either individually, or if you want just make a getter 
// for the entire group of data, so you can use it just like you would a 
// separate UserData object 
send_double_opt_in($user->getUserData()); 
?> 

---

संपादित करें अधिक जानकारी पता करने के लिए प्रदान की:

---

तो यह मेरे थे, मैं कुछ अधिक (के लिए, कहते हैं, एक नया उपयोगकर्ता बनाने) के बाद कैसा लगा था

आप कहते हैं कि ये गुण उपयोगकर्ताEntity के बाहर मौजूद हैं, और वे संभावित रूप से अपने आप पर रह सकते हैं ... क्या आपका मतलब यह है कि इन गुणों को उपयोगकर्ता एंटिटी के लिए भी उद्देश्य के बिना एकत्रित, उपयोग और त्याग दिया जा सकता है bject? यदि ऐसा है, तो उस डेटा के लिए एक अलग वस्तु पूरी तरह उपयुक्त होगी। यदि नहीं, तो डेटा हमेशा किसी मौजूदा या भविष्य उपयोगकर्ता एन्टीटी के अधीनस्थ होता है, तो वे गुण कभी भी "अपने आप पर" नहीं रहेंगे ... चलो इसे "वैश्विक डेटा" बिंदु देखें। जब आप पूरी प्रणाली को पूरी तरह से मानते हैं, न केवल पल से पल तक कोड, यह संभावना है कि डेटा उपयोगकर्ता एंटिटी वर्ग से संबंधित है।

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

1. कन्स्ट्रक्टर में डेटा को मान्य करें। समस्या यह है कि यदि यह मान्य नहीं है, तो आपको डेटाबेस प्रविष्टि को हटाना होगा। बदसूरत।
2. डेटा सत्यापन के साथ, कन्स्ट्रक्टर में डेटाबेस इंटरैक्शन ले जाएं। यह आपके पसंदीदा ऑब्जेक्ट मॉडल का उल्लंघन कर सकता है, और आपको इसे बनाए जाने के बाद ऑब्जेक्ट की स्थिति की जांच करनी होगी (यानी सार्वजनिक संपत्ति $this->status = 'error'; सेट करें या ऐसा कुछ आपको यह बताने के लिए कि कुछ बुरा हुआ है जिसे आपको संभालना होगा) ।
3. डेटा को सत्यापित करने के लिए एक स्टैंडअलोन फ़ंक्शन बनाएं। बदसूरत, क्योंकि यह एक ऐसा फ़ंक्शन है जो विशेष रूप से UserEntity और/या उसके डेटा से संबंधित है।
4. या, बस एक अलग उपयोगकर्ता डेटा वस्तु बनाएं जैसे आपने सुझाव दिया है और इसके साथ किया जाना चाहिए। चरण # 2 की तरह, आपको असफल सत्यापन इंगित करने के लिए $status संपत्ति का कुछ प्रकार होना होगा।

Answer 2

ऐसा लगता है कि यह वैधकर्ताओं के एक सेट के लिए एक अच्छा मामला होगा जिसका उपयोग किसी भी डोमेन ऑब्जेक्ट से स्वतंत्र रूप से किया जा सकता है - शायद यह मेरा कार्यात्मक-प्रोग्रामिंग पक्ष आ रहा है, लेकिन मुझे कोई समस्या नहीं दिखाई दे रही है isValidEmail() जैसे कार्यों का एक समूह बनाने के साथ।

मैं समझता हूं कि आप स्थिर कार्यों के समूह के साथ असहज हैं; चीजों को साफ रखने के लिए, क्या आप इसके बजाय विधियों के समूह के साथ एक स्थिर Validator कक्षा पर विचार करेंगे?

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