रेपोजिटरी के साथ या बिना एनएचबर्ननेट

Question

इस मामले पर कई समान प्रश्न हैं, मुझे अभी भी यह तय करने के लिए पर्याप्त कारण नहीं हैं कि किस तरह से जाना है।

असली सवाल यह है कि, यह abstract the NHibernate using a Repository pattern, या not के लिए उचित है?

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

एक विकल्प व्यापार परत पर IQueryable<T> का पर्दाफाश करने और LINQ का उपयोग करने का उपयोग करना है, लेकिन मेरे अनुभव से LINQ समर्थन अभी भी NHibernate में पूरी तरह लागू नहीं किया गया है (प्रश्न केवल हमेशा अपेक्षित काम नहीं करते हैं, और मुझे डिबगिंग पर समय बिताना नफरत है एक ढांचा)।

हालांकि मेरी व्यावसायिक परत में एनएचबर्ननेट का संदर्भ देने से मेरी आंखें दर्द हो जाती हैं, यह डेटा पहुंच का एक अमूर्त होना चाहिए, है ना?

इस पर आप क्या राय रखते हैं?

Answer 1

अच्छा प्रश्नोत्तरी। मैं कुछ दिन पहले उनके बारे में भी सोच रहा था।

वास्तव में, एनएचबीरनेट 3.0 अल्फा (या वर्तमान ट्रंक) को आज़माएं, इसका नया LINQ प्रदाता पिछले लोगों की तुलना में काफी अधिक है। (अब तक मुझे केवल एक विधि मिल रही है जो काम नहीं कर रही है, लेकिन अगर आप किसी चीज में भाग लेते हैं तो यह आपके स्वयं के तंत्र में हुक करना संभव है, यह डिफ़ॉल्ट रूप से समर्थन नहीं करता है।) मुझे वर्तमान में उपयोग करने के साथ कोई समस्या नहीं है (अभी तक?) सूँ ढ। आप http://www.hornget.net/packages/ साइट पर एक "रात्रि" निर्माण पा सकते हैं, इसके साथ फ्लूएंट हाइबरनेट निर्माण के साथ। यदि आप जानते हैं कि इसका उपयोग कैसे किया जाए तो Fluent वास्तव में आपकी उत्पादकता बढ़ाता है। एसओ समुदाय really helped me with that भी।

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

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

IQueryable<T> का खुलासा करना एक बहुत अच्छा विचार है, और यह वही है जो अभी कई रिपोजिटरी कार्यान्वयन कर रहे हैं। (और मैं भी, हालांकि मैं इसे एक स्थिर वर्ग में लिखना पसंद करता हूं।) और निश्चित रूप से आपको किसी इकाई को सम्मिलित करने या अपडेट करने के लिए कुछ तरीकों का खुलासा करना होगा, या लेन-देन शुरू करने और लेनदेन करने के तरीके, यदि आप चाहते हैं। (BeginTransaction सिर्फ एक IDisposable लौट जाना एक NHibernate इंटरफ़ेस बाहर लीक से बचने के लिए, और कहा कि ठीक हो जाओगे।)

मैं आपको कुछ दिशा-निर्देश दे सकते हैं: SharpArchitecture या FubuMVC योगदान के कार्यान्वयन की जाँच कैसे करते हो के बारे में कुछ विचार प्राप्त करने के लिए यह सही है, और यह how I solved it है।

Answer 2

मैं बस एक बड़ा हाँ कहूंगा! एक रिपोजिटरी पैटर्न है, चीजों को सार रखें!

Answer 3

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

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