क्या यह मेरी मूर्खता है कि मेरे प्रोजेक्ट के लिए एनएचबीरनेट का उपयोग न करें?

Question

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

तो, क्या मैं सुनने के लिए आप से चाहते हैं, यह वास्तव में इस स्थिति में NHibernate का उपयोग नहीं करने के लिए बेवकूफ है? क्या मैं वास्तव में अज्ञानी हूं या क्या यह मेरे स्वयं के समाधान का उपयोग करने के लिए इतना अजीब विचार नहीं है?

Answer 1

मुझे लगता है कि वास्तव में इन दिनों वहाँ अपने स्वयं के हठ ढांचे रोल करने के बाद से वहाँ इतने सारे अच्छे विकल्प वहाँ बाहर हैं किसी भी कारण नहीं है। आपको NHibernate का उपयोग करने की आवश्यकता नहीं है (हालांकि यह एक अच्छी पसंद है) लेकिन मैं गंभीरता से कुछ ऐसी चीज का उपयोग करने पर विचार करता हूं जो उद्योग में अच्छी तरह से परीक्षण और स्थापित है क्योंकि यह बेहतर प्रदर्शन करेगा और आपके द्वारा लिखे गए कुछ भी कम बग्स होंगे।

Answer 2

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

Answer 3

लोग चौखटे कि पहले से ही लिखा जाता है, क्योंकि अच्छी तरह से, वे पहले से ही लिखा रहे हैं (और परीक्षण किया) का उपयोग करते हैं।

लेकिन आपके खुद को रोल करने के लिए योग्यता है। केवल आप और आपके सहयोगी आपके डोमेन के बारे में धारणाएं बना सकते हैं। NHibernate जैसे एक सामान्य ढांचे में कई धारणाएं नहीं हो सकती हैं, क्योंकि इससे यह बहुत सार्वभौमिक नहीं होगा।

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

Answer 4

आपके पास कई संभावनाएं हैं जो शायद पहिया को पुनर्निर्मित करने से बेहतर हैं। अपने DAL + डीएओ के लिए

1. उपयोग इकाई की रूपरेखा: मुझे दो सबसे अधिक संभावना विकल्प नाम हैं। यह आपकी कक्षाएं (जिसे आपने पहले ही लिखा है) अप्रचलित कर देगा, क्योंकि ईएफ अपना स्वयं का निर्माण करेगा और आप नवीनतम भाषा क्षमताओं और तकनीकों के साथ अद्यतित होंगे।

2. फ्लुएंट एनएचबेर्नेट का उपयोग करें ताकि आपको एक्सएमएल मैपिंग के साथ काम करने की आवश्यकता न हो। इस तरह आप अपने व्यवसाय परत ऑब्जेक्ट क्लास को आपके द्वारा लिखे गए हैं और थकाऊ NHibernation XML फ़ाइलों से बचेंगे। यह सब सी # है।

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

यदि मैं आप थे, तो मैं # 2 विकल्प के साथ जाऊंगा, क्योंकि मैंने विकल्प # 1 किया है और मुझे पता है कि मुझे ईएफ काम करने के लिए बहुत सी चीजों को कस्टमाइज़ करना था। ईएफ वी 2 के साथ तैयार हो जाएगा।

Answer 5

मैं आपको मूर्ख नहीं कहूंगा क्योंकि मैंने अतीत में वही काम किया है। तब मैंने NHibernate का उपयोग करना शुरू कर दिया और आश्चर्य किया कि मैंने अपना खुद का रोल क्यों किया। यह अच्छा है, इसे जाने दो।

Answer 6

मुझे लगता है कि यह नियंत्रण संतुलन का विषय है। आप कहते हैं कि आप नियंत्रण चाहते हैं और आप मैपिंग नहीं चाहते हैं। यदि यह नियंत्रण लागत पर आता है कि विकास और रखरखाव लागत में वृद्धि हुई है और यह कामकाजी कोड बनाने में अधिक समय लगता है, तो यह एक समस्या है।

मुझे व्यक्तिगत रूप से एक ढांचे को घुमाने में कोई समस्या नहीं दिखाई देती है जब तक कि यह एक दोहराव वाले कार्य को सरल बनाता है और विकास के लिए कम कमरे के कारण विकास को अधिक उत्पादक और कोड अधिक स्थिर बनाता है। हमने अपना खुद का ढांचा तैयार किया है, जिसमें एक दृढ़ता/डेटा पहुंच कार्यान्वयन शामिल है। हालांकि, ऐसा करने के हमारे कारण विशिष्ट थे। इस मामले में, यह एक डीडीडी पर्यावरण के भीतर काम करना था जो शेल्फ उत्पादों को प्रदान करने वाले अधिकांश चीज़ों के मुकाबले इवान्स के वर्णन के करीब था।

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

Answer 7

वहां बहुत अच्छे दृढ़ता उपकरण हैं जो अच्छी तरह से परीक्षण किए जाते हैं और सिद्ध प्रदर्शन (NHibernate, Linq to entities, LLBL Gen Pro) हैं। यदि आपकी ज़रूरतें सामान्य दृढ़ता ढांचे से बहुत अलग हैं तो मैं अपना खुद का रोल करूंगा। यदि संभव हो, तो मैं मौजूदा उपकरण के परीक्षण और अनुकूलन का लाभ लेना चाहता हूं।

कहा जा रहा है कि अगर मैं अपना खुद का ओआरएम उपकरण बनाने का अनुभव करना चाहता हूं तो मैं खुद को भी रोल कर सकता हूं और डाउनसाइड्स के साथ रहने के लिए तैयार था (साथ ही वर्षों के आसपास के उपकरणों के रूप में परीक्षण या अनुकूलित नहीं किया गया था , बाज़ार जाना)।

Answer 8

अपना स्वयं का समाधान बनाना, खासकर जब यह ठीक काम करता है और जैसा कि आप कहते हैं उतना सरल हो, न तो अज्ञानी और न ही अजीब है। ऐसी कई स्थितियां हैं जहां एनएचबर्ननेट जैसी अलग परियोजना पर निर्भरता जोड़ने की तुलना में ऐसा करना बेहतर होता है।

यह कहा गया है कि निश्चित रूप से ऐसी कई स्थितियां भी हैं जहां पूर्ण विपरीत सत्य है। :)

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

Answer 9

यहां सभी उत्तरों बहुत अच्छे हैं, लेकिन मुझे आश्चर्य है कि किसी ने भी Castle ActiveRecord का उल्लेख नहीं किया है, यह आपके ढांचे के समान ही लगता है और वास्तव में इंटरफ़ेस को NHibernate को सरल बनाता है। यह उन पैटर्नों में से एक है जिसने रूबी को रेल पर इतना लोकप्रिय बना दिया!

Ayende Rahien (प्रिंसिपल राष्ट्रीय राजमार्ग डेवलपरों में से एक) कुछ साल पहले Oredev पर ActiveRecord पर एक बड़ा प्रस्तुति दी जो मैं अत्यधिक की सिफारिश: http://www.viddler.com/explore/oredev/videos/89

Answer 10

हम भी हमारे अपने डेटा एक्सेस परत और इकाई वर्गों का उपयोग कर रहे थे। हमारे पास कोड जनरेटर भी था जो हमारे लिए इन सभी वर्गों को उत्पन्न करता था। लेकिन अब हम इकाई फ्रेमवर्क का उपयोग कर रहे हैं और हम और अधिक खुश हैं।

सरल सलाह: nHibernate सीखना शुरू करें या जो भी आप पसंद करते हैं और अपनी अगली परियोजना में इसका उपयोग करना शुरू करें।

Answer 11

यह "मूर्ख" द्वारा उनके अर्थों पर निर्भर करता है।

यदि "मूर्ख" द्वारा उनका मतलब है कि आपको अपनी दृढ़ता परत को पहले स्थान पर नहीं लिखा जाना चाहिए था, तो वे शायद सही हैं, लेकिन यह मसालेदार दूध पर रो रहा है।

यदि "मूर्ख" द्वारा उनका मतलब है कि आपको अपने सभी मौजूदा कोड को फिर से लिखना चाहिए ताकि यह आपके साथ पहले से काम कर रहा हो, तो वे शायद गलत हैं (हालांकि इसमें # बग्स के लिए कुछ कहा जा सकता है NHibernate बनाम आपकी # में बग की संभावना है)।

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

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

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

Answer 12

इकाई रिक्त स्थान - http://www.entityspaces.net/Portal/Default.aspx

भी एक अच्छा उपकरण है।

Answer 13

मैं नौकरी के लिए फ्लुएंट एनएचबेर्नेट का उपयोग कर समाप्त हुआ। मेरी सभी इकाई कक्षाएं ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)