क्यों मेरी चिंताओं को अलग करना डाटाबेस/बिजनेस ऑब्जेक्ट्स/वेब सेवा, मुझे और कोड लिखता है?

Question

मैंने सॉफ़्टवेयर डिज़ाइन पर बहुत सी किताबें पढ़ी हैं, और अधिक से अधिक मैं सोच रहा हूं कि क्या मैंने व्यवसाय ऑब्जेक्ट और सीरियलाइजेशन के बीच चिंता को अलग करने के बारे में सीखा है, मुझे और अधिक उत्पादक बनाता है।

मैं डोमेन संचालित डिजाइन से प्रभावित हूं, इसलिए जब मैं अपने व्यवसाय वर्गों को डिजाइन करता हूं तो मैं दृढ़ता के बारे में नहीं सोचता। मेरे डेटाबेस/वेब सेवा प्रौद्योगिकी/कैशिंग प्रौद्योगिकी के साथ मिलकर एकमात्र ऑब्जेक्ट्स एक अच्छे डोमेन इंटरफ़ेस के साथ एक भंडार के पीछे encapsulated हैं।

एक पारंपरिक अनुप्रयोग डेटाबेस < -> वेब सेवा < -> आरआईए, मैं अपने व्यवसाय वर्ग खाता और कर्मचारी डिजाइन करता हूं, उदाहरण के लिए। फिर यदि मैं डेटा स्रोत से खाता प्राप्त करना चाहता हूं तो मैं एक IAccountRepository बना सकता हूं, और क्वेरी करने के तरीकों को लागू कर सकता हूं, या अपने डेटा स्रोत में खाते जोड़ सकता हूं।

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

डेटाबेस रिपॉजिटरी को कार्यान्वित करने के लिए, मैं एक ओआरएम का उपयोग करता हूं जो मेरे डेटाबेस स्कीमा से कक्षाएं बनाता है, फिर मैं डेटाबेस कक्षाओं में/से व्यवसाय वर्गों को बदलने के लिए एक अनुवादक का उपयोग करता हूं, इस प्रकार मेरी व्यावसायिक कक्षाएं मेरे डेटाबेस स्कीमा से decoupled हैं।

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

जब मैं अपना आरआईए एप्लिकेशन बनाता हूं, तो मैं फिर से अपना डोमेन मॉडल डिज़ाइन करता हूं, लेकिन इस बार भंडार कार्यान्वयन डेटाबेस (और फिर अनुवादकों) के बजाय एक webservice का उपयोग करता है।

WPF डेवलपर्स के लिए, मैं तब अपना व्यूमोडेल और मेरा दृश्य बना देता हूं।

मैं इस तरह के कार्यक्रम का उपयोग करता था।

लेकिन, जब मेरे मालिक आता है और कहता है: आप इस फार्म के लिए एक क्षेत्र में जोड़ सकते हैं ... ऐसा ऐसा मैं चाहिए करने के लिए: मेरे डेटाबेस

1. अद्यतन
2. अद्यतन मेरी डेटाबेस अनुवादक
3. अद्यतन अपने व्यवसाय वस्तु
4. अद्यतन अपने वेब सेवा अनुवादक (सर्वर)
5. अद्यतन अपने वेब सेवा अनुवादक (ग्राहक)
6. अद्यतन अपने व्यवसाय वस्तु (ग्राहक) मेरे विचार
7. अद्यतन
8. WPF adepts के लिए, मेरे ViewModel अद्यतन

मैं अधिक से अधिक जोड़े डेटाबेस का उपयोग प्रौद्योगिकी और वेब सेवा के साथ अपने व्यवसाय वस्तु के लिए सोच रहा हूँ प्रौद्योगिकी या क्रमबद्धता प्रौद्योगिकी।

इस तरह मुझे अब अपने अनुवादकों को बनाए रखने की आवश्यकता नहीं है। उदाहरण के लिए व्यापारिक वस्तुओं पर इन तकनीकों के गुण/एनोटेशन का उपयोग क्यों नहीं करते? हां यह कुछ बाधाओं को लाता है, हां मुझे अपने खेतों पर एक सेट/सेट की आवश्यकता होगी, भले ही मैं अपनी संपत्ति को पढ़ना चाहूंगा, हां, मेरे व्यापार मॉड्यूल में बाहरी निर्भरताएं होंगी। लेकिन मुझे लगता है कि इसका परिणाम कम कोड होगा, और एक अधिक रखरखाव प्रणाली होगी।

मेरे भंडारों का कार्यान्वयन तुच्छ होगा, और अनुवादकों पर भरोसा नहीं करेगा।

हालांकि मुझे इस तरह के कोड के फायदे दिखाई देते हैं, मैं हमेशा इस तरह के कोड के लिए दोषी महसूस करता हूं। मैं अपने व्यापारिक वस्तुओं पर अपनी डेटा एक्सेस प्रौद्योगिकी/वेब सेवा प्रौद्योगिकी/सीरियलाइजेशन तकनीक के साथ 5 विशेषताओं/एनोटेशन जोड़ने के बारे में वास्तव में दोषी महसूस करता हूं और मुझे लगता है कि यह सही नहीं है।

क्यों मेरी चिंताओं को अलग करना डाटाबेस/बिजनेस ऑब्जेक्ट्स/वेब सेवा, मुझे और कोड लिखता है?

क्या आपके पास कुछ विकल्प हैं?

Answer 1

आपकी व्यक्तिगत उत्पादकता बिंदु नहीं है।

चिंताओं को अलग करने का बिंदु मूल्य आपके द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर के उपयोग योग्य, रखरखाव और अनुकूलनीय बनाने के लिए है।

मुझे खेद है कि इससे आपको अधिक कोड लिखने में मदद मिलती है, लेकिन आपका समय आम तौर पर आपके द्वारा लिखे गए लेखन, रखरखाव और अनुकूलन की जीवन-समय लागत का एक छोटा सा अंश है।

स्वामित्व की जीवनभर की कुल लागत को बनाए रखने के लिए चिंताओं का पृथक्करण अनिवार्य रूप से है। आपकी व्यक्तिगत उत्पादकता के साथ इसका कोई संबंध नहीं है।

यदि आपका मालिक आपको व्यापक परिवर्तन के लिए पूछ रहा है ... अच्छा ... यह व्यापक है। मुझे खेद है कि यह व्यापक है।

---

संपादित करें 1

मूल्य अपने सॉफ़्टवेयर के मूल्य है कि लोगों को द्वारा निर्मित है इसे का उपयोग है।

"क्या यह कोड की शुद्धता/सुंदरता है? मेरे लिए, मूल्य सादगी और पठनीयता में है।" यह न तो है। यह वास्तविक मूल्य की समस्याओं को कोड लागू करने वाला मूल्य है।

यदि कोड को बनाए रखने, अनुकूलित करने या उपयोग करने के लिए कठिन है, तो यह इसे कम करता है। यदि कोड को बनाए रखने, अनुकूलित करने या उपयोग करने में आसान है, तो कोड से पूर्ण मूल्य प्राप्त करने के लिए कम बाधाएं हैं।

कोड का विकास करने का आपका समय इसका उपयोग करने के मूल्य की तुलना में एक छोटी, छोटी लागत है। साथ ही, आपका समय विकसित करना या अनुकूलन की तुलना में एक छोटी सी लागत है।

संपादित 2

व्यापक परिवर्तन सॉफ्टवेयर के निर्माण का एक अपरिहार्य परिणाम है। कुछ भी नहीं - कोई अभ्यास नहीं - आपके बॉस को आपके आर्किटेक्चर को तोड़ने वाले बदलाव से रोका जा सकता है।

यदि आपके पास एक परत है, तो लगभग कोई भी परिवर्तन उस परत को तोड़ देता है।

यदि आपके पास 3 स्तर, 7 परतें या एन + 1 परतें हैं, तो आपके बॉस के लिए एक से अधिक परत तोड़ने वाले बदलाव के लिए हमेशा पूछना संभव है।

विचार यह है कि अधिकांश परिवर्तन अलग-अलग हैं। कुछ भी आश्वस्त नहीं कर सकता कि सभी परिवर्तन अलग हैं।

Answer 2

एक रखरखाव योग्य एप्लिकेशन है जिसमें रखरखाव की कम लागत है। यदि सामान्य परिवर्तन लंबे समय तक लेते हैं, तो यह एक रखरखाव योग्य अनुप्रयोग नहीं है।

पूछने का मुख्य सवाल यह है कि तकनीकी परिवर्तनों के विपरीत, सामान्य सुविधा अनुरोध कैसे हैं।

आप अपने पसंदीदा प्रौद्योगिकी हर 3 महीने सेट या ऐसा है, तो आप नई सुविधाओं को लागू करने के लिए समय कभी नहीं होगा बदलते हैं तो तो अपने वास्तुकला इष्टतम है, ...

Answer 3

मैं भी यही अनुभव है, की बहुत है विद्यालय में मैंने सामानों के बारे में सीखा और "सामान" को अलग करने के बारे में सीखा है, जो वास्तव में मेरे कोड को अधिक जटिल बनाता है।

मुझे एहसास हुआ है कि, जब आपके पास उच्च समेकन होता है (आपकी कक्षाएं बहुत छोटी होती हैं और बहुत ही बिंदु पर होती हैं), तो आप उच्च युग्मन कर सकते हैं। प्रत्येक व्यक्तिगत वर्ग को आगे और आगे सरलीकृत करके, प्रत्येक घटक स्वयं से अधिक से अधिक बेकार होगा; सरल कार्यक्षमता प्राप्त करने के लिए आपको इन सरल "समेकित" वस्तुओं के बीच जटिल इंटरैक्शन प्रबंधित करने की आवश्यकता होगी।

फिर, सरल कार्य जटिल होंगे !! जावा में एक फ़ाइल पढ़ने के बारे में सोचें, मुझे याद नहीं है कि इसे कैसे करें (मुझे इसे कई बार करना पड़ता है), और मैं इसे फिर से नहीं करना चाहता हूं।

अजगर में यह मृत सरल है: चिंताओं और कपोल-कल्पना की

for line in open("filename"): 
    # do something with line 

मैं यह नहीं कह रहा हूँ जुदाई बुरा कर रहे हैं, बस उन्हें sanely है।

आईएमओ, यह कुछ ऐसा होता है जो "केवल काम करता है" भले ही यह स्पेगेटी हो, भले ही आप रिफैक्टर करें।

Answer 4

आप निश्चित रूप से बहुत अधिक कोड लिख रहे हैं। एक फ़ील्ड जोड़ना 8 कदम की प्रक्रिया नहीं होनी चाहिए।

1. NHibernate का उपयोग क्यों नहीं करें? जब तक आपका सच्चा डोमेन मॉडल न हो और आप "डेटाबेस अनुवादक" (अब) FluentNHibernate के साथ एक सरल अभ्यास कर सकते हैं।

2. अपेक्षाकृत पारदर्शी तरीके से चरण 4-6 के संयोजन के लिए वहां कुछ बहुत मजबूत ढांचे हैं। एक के लिए डब्ल्यूसीएफ (डरावनी!)।

Answer 5

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

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

मेरी डेवलपर्स के साथ

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

मैं लहर प्रभाव के डर को समझता हूं। ईमानदार होने के लिए, हमेशा किसी तरह का लहर बनने वाला होता है। एक उचित ढंग से डिज़ाइन किए गए भंडार के साथ, आप केवल कुछ स्थानों के लिए लहर के आकार को अलग कर सकते हैं। चूंकि ऐसा प्रतीत होता है कि आप .NET (WPF टिप्पणी के आधार पर) का उपयोग कर रहे हैं, तो आप .NET Domain-Driven Design with C#: Problem - Design - Solution पर एक नज़र डालना चाहेंगे। हालांकि मैं नमूना में कार्यान्वयन के 100% से सहमत नहीं हूं, यह वास्तव में यह दर्शाता है कि यह दृष्टिकोण वास्तव में कितना अच्छा काम कर सकता है।

Answer 6

किसी एप्लिकेशन को डिज़ाइन करते समय, अमूर्तता के स्तर को मूल्य प्रदान करना चाहिए। उन्हें वहां नहीं होना चाहिए क्योंकि यह एक 'सर्वोत्तम अभ्यास' है। कुछ अनुप्रयोगों में समृद्ध डोमेन मॉडल होता है और अमूर्त परतों से लाभ होता है। हालांकि, एक आवेदन जो बहुत अधिक तर्क के बिना बहुत डेटा केंद्रित है, उसे कई परतों की आवश्यकता नहीं हो सकती है।

मैं कुछ अनुप्रयोगों कि नाम कर्तव्यनिष्ठा परत EmployeeDL, EmployeeBL, EmployeeUL मिलान के साथ प्रत्येक वस्तु के लिए इसी कई परतों को परिभाषित देखा है। किसी भी ऑब्जेक्ट में कोई भी मूल्य नहीं जोड़ा गया है और उपयोगकर्ता इंटरफ़ेस से डेटाबेस में परतों के बीच बस मूल्यों को पारित किया गया है। यह व्यर्थ था।

मुझे लगता है जब एक अमीर डोमेन मॉडल के साथ आवेदन पत्र के साथ काम करने, परिवर्तन कई परतों को प्रभावित कर सकता है, लेकिन शायद ही कभी डेटाबेस के लिए कई परतों के माध्यम से यूआई से एक मूल्य गुजर के रूप में सरल है। मध्य में व्यापार तर्क है जो अमूर्तता के स्तर के बिना लागू करना अधिक कठिन होगा।

दिन के अंत में, यह एक वास्तुकला कि इसकी जटिलता और रख-रखाव के मामले में आपके आवेदन की जरूरतों से मेल खाता चयन करने के लिए सबसे महत्वपूर्ण है।

Answer 7

आप किस उपकरण का उपयोग कर रहे हैं? मैंने इस तरह की उच्च डिग्री गैर-स्वचालित बकवास के बारे में कभी नहीं सुना है। मुझे विश्वास नहीं है कि आपका प्रश्न वास्तविक है। और आप ग्राहक पर "व्यावसायिक वस्तु" के साथ क्या कर रहे हैं?

आप अपने डेटा एक्सेस, व्यापार और वेब सेवा परतों को युग्मित करने के बारे में बात करते हैं। यह वही है जहां जोड़े के लिए नहीं है!

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

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

सावधान रहें कि आप क्या पूछते हैं!

Answer 8

इन बातों को अलग करने की बात यह है

• एक डेवलपर एक टुकड़ा पर काम करता है
• प्रत्येक टुकड़ा और अधिक आसानी से इकाई

परीक्षण किया जब तक आप 8 डेवलपर्स है (अपने आठ मैच के लिए किया जा सकता है -पीस पाई), और उत्पादन कोड से मेल खाने के लिए यूनिट-टेस्ट कोड लिख रहे हैं, आपकी व्यवस्था अधिक है।

Answer 9

अबास्ट्रक्शन परतों के उपयोग पर भी विचार करें जिन्हें एक साधारण पास-थ्रू के साथ कार्यान्वित किया जा सकता है लेकिन आवश्यकता होने पर ओवरराइड किया जा सकता है।

डेटाबेस दृश्य एक अच्छा उदाहरण हैं - मेरे पास आमतौर पर ऐप-लेयर केवल टेबल नामों के बजाय दृश्यों (स्पष्ट रूप से _v प्रत्यय द्वारा इंगित) के माध्यम से डेटाबेस तालिकाओं का संदर्भ देता है। ये आम तौर पर एक एकल तालिका का संदर्भ देते हैं और प्रत्येक डीडीएल की केवल 2 लाइनें हैं। यह बनाना और बनाए रखना आसान है - लेकिन ऐप, ओआरएम & डेटाबेस के बीच अनुवाद प्रदान करने के लिए भी विस्तारित किया जा सकता है।

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

तो, दोनों मामलों में आपको अमूर्त परत का मूल्य मिलता है, लेकिन जब आपको वास्तव में लचीलापन की आवश्यकता होती है तो केवल कोड & श्रम जोड़ें।