मैट,
मैं कहूंगा कि आपकी दुकान प्रक्रियात्मक कोड लिख रही है। मैं यह स्पष्ट करना चाहता हूं कि प्रक्रियात्मक कोड का उपयोग करके कई बड़ी प्रणालियों (जिनमें मैंने कई काम किए हैं) के साथ कुछ भी गलत नहीं है। इसके लिए एक समय और जगह है।
अब प्रक्रिया मॉडल के पास डोमेन मॉडल में कोई स्थान नहीं है। यदि आप एक और अधिक प्रक्रियात्मक शैली का उपयोग करना चाहते हैं जो ठीक है लेकिन इसे टेबल मॉड्यूल या सक्रिय रिकॉर्ड पैटर्न जैसे कुछ के साथ उपयोग करें।यह ओओ की कमी नहीं है कि मैं मार्गदर्शन में इतनी विनाशकारी होने पर विचार कर रहा हूं लेकिन प्रक्रियात्मक तर्क के साथ एक डोमेन मॉडल का उपयोग।
इससे डोमेन परत (आमतौर पर रखरखाव) के किसी भी लाभ प्राप्त किए बिना डोमेन परत (प्रतिबाधा विसंगति, समेकन प्रक्रिया, अलगाव, सर्वव्यापी भाषा आदि बनाने के लिए सोचा प्रक्रिया समय) बनाने के लिए बड़ी मात्रा में संसाधनों का खर्च होता है। अन्यथा प्रदान करते हैं। दूसरे शब्दों में जब आप अपनी कार्यात्मक आवश्यकताओं को पूरा कर सकते हैं तो ठीक है आप लगभग अपने रिटर्न के साथ अपने बजट की एक बड़ी राशि खर्च करते हैं।
अब "व्यवहार है" पर वापस आने के लिए मैं एक "डोमेन संचालित डिजाइन" दृष्टिकोण के विपरीत ऑब्जेक्ट ओरिएंटेड से प्रश्न पर ध्यान केंद्रित करना चाहता हूं। एक वस्तु आम तौर पर कुछ राज्य को समाहित करेगी और आम तौर पर कुछ व्यवहार का पर्दाफाश करेगी।
त्वरित पुनरावृत्ति: राज्य संपुटित, बेनकाब व्यवहार
तो क्या व्यवहार एक वस्तु होना चाहिए? बस रखो यह उन व्यवहारों का होना चाहिए जो राज्य पर संचालित होते हैं, यह encapsulating है। एक आदर्श व्यवहार ओओ दुनिया में राज्य कभी वस्तु के व्यवहार से अवगत नहीं होगा। कोड में चतुराई रखो अगर हम कोड की तरह देखने लगते हैं:
Customer c = GetCustomerFromRepository();
c.Status = CustomerStatuses.Deleted;
c.LastUpdated = DateTime.Now;
c.UpdatedBy = GetCurrentUser();
CustomerRepository.Save(c);
हम एक SRP उल्लंघन किया है ... यह कोड कोड है कि ग्राहक वस्तु का एक व्यवहार होना चाहिए क्योंकि ग्राहक वस्तु की "जिम्मेदारी" करने के लिए है ।
किसी ग्राहक के बारे में स्थिति को समाहित करें और व्यवहार का पर्दाफाश करें।
जैसा कि हम देख सकते हैं कि हम ग्राहक होने से बेहतर होंगे। हटाएं() विधि। (हाँ यह एक बुरा उदाहरण है जो मुझे पता है ...)
अब हम टीडीडी का उपयोग करके भी इसे प्राप्त करेंगे। सीम के साथ परीक्षण में सौदा करना हमारे लिए बहुत आसान है कि व्यवहार उन सीमों से प्रदान करता है जहां सभी राज्य उजागर होते हैं। इसका कारण यह है कि मुझे अपने परीक्षणों में तर्क को डुप्लिकेट करने की आवश्यकता नहीं है। क्लाइंट कोड देखभाल कैसे हटाता है ... यह केवल परवाह करता है कि ग्राहक व्यवहार का खुलासा करता है। सी.स्टेट == ग्राहकस्टेट्स। हटाए गए और सी। अपडेटेडबी == GetCurrentUser() इत्यादि के बारे में हमारे परीक्षणों में इस तरह के प्रयासों के रूप में हम बस जोर देकर कहते हैं कि एक नकली उपयोग करके ग्राहक सीम पर हटाई गई विधि को बुलाया गया था।
अब शीर्षक पर वापस आने के लिए। किसी व्यावसायिक वस्तु में होने वाले तर्क की मात्रा तर्क की मात्रा है जो इसके राज्य को समाहित करने की ज़िम्मेदारी के तहत आती है। कभी-कभी यह बहुत है, कभी-कभी इसकी नहीं। ऐसे स्थान हैं जहां आप सेवाओं का भी उपयोग करना चाहते हैं ... एक अच्छा उदाहरण किसी दिए गए व्यवहार के लिए कई डोमेन ऑब्जेक्ट्स के बीच बातचीत को समन्वयित करेगा, लेकिन यहां तक कि सेवा को डोमेन ऑब्जेक्ट्स पर व्यवहार पर कॉल करना चाहिए।
क्या इससे चीजों को थोड़ा सा स्पष्ट करने में मदद मिलती है?
ग्रेग
मैं वास्तव में आपके साथ 100% सहमत हूं, लेकिन मेरी दुकान एसओए बैंडवागन पर कूद गई है, और यहां डीटीओ या संदेश शैली इकाइयों की ओर एक मजबूत गति है। क्या आप तर्क देंगे कि रिपोजिटरी पैटर्न स्वाभाविक रूप से त्रुटिपूर्ण है? जब आपकी ग्राहक वस्तुएं स्वयं को सहेज सकती हैं तो काम की इकाई कैसे फिट होती है? –
ओह हाँ, और एक पूरी तरह से अलग मंच में जवाब देने के लिए समय निकालने के लिए धन्यवाद, तो आपका ब्लॉग :-) –
मुझे लगता है कि ग्रेग की टिप्पणी है कि ग्राहक। डिलीट() विधि खराब है इसका मतलब यह है कि यह एक विधि नहीं है जिसे आप आम तौर पर रखेंगे डोमेन मॉडल (ग्रेग, अगर मैं गलत हूं तो कृपया मुझे सही करें।) यह ActiveRecord मॉडल में फिट होगा। रिपोजिटरी टूटा नहीं है, यह एक विशिष्ट उद्देश्य के लिए है: सतत मॉडल। –