एनएचबीरनेट और कॉर्पोरेट बिजनेस लॉजिक

Question

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

यहां कंपनी में, हमारे पास एक मौजूदा एएसपी.नेट वेब अनुप्रयोग है। .NET Framework 3.5 SP1 पर सी # एएसपी.नेट में लिखा गया। कुछ समय पहले डब्ल्यूसीएफ और एसओएपी का उपयोग करके इस वेब एप्लिकेशन के लिए प्रारंभिक एपीआई विकसित की गई थी ताकि बाहरी पार्टियों को ब्राउज़र पर भरोसा किए बिना आवेदन के साथ संवाद करने की अनुमति मिल सके।

यह एपीआई कुछ समय तक जीवित रहा, लेकिन आखिरकार यह अनुरोध एक नया एपीआई बनाने आया जो RESTfull था और नई प्रौद्योगिकियों पर निर्भर था। मुझे यह असाइनमेंट दिया गया था, और मैंने माइक्रोसॉफ्ट एमवीसी 2 फ्रेमवर्क का उपयोग करके प्रारंभिक एपीआई बनाया, जो हमारे एएसपी.नेट वेब अनुप्रयोग के अंदर चल रहा था। शुरुआत में इसे ठीक से चलाने के लिए कुछ समय लगेगा, लेकिन फिलहाल हम अपने संसाधनों का विस्तार करने वाले एक्सएमएल प्राप्त करने के लिए एप्लिकेशन पर आरईएसटी कॉल कर पाएंगे।

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

डेटा सेवाओं के साथ काम करने के लिए एनएचबीर्नेट 2 प्राप्त करने के लिए इंटरनेट खोजने के बाद, मैं एपीआई का एक रीडऑनली संस्करण बनाने में सफल रहा जो हमें आने वाले प्रश्न अनुरोधों को मैप करके आंतरिक व्यापार परत से इकाइयों को पढ़ने की अनुमति देता है व्यापार परत हालांकि, हम एक कार्यात्मक एपीआई चाहते हैं जो ओडाटा प्रोटोकॉल का उपयोग करके इकाइयों के निर्माण की अनुमति भी देता है। तो अब मैं आगे बढ़ने के लिए थोड़ा फंस गया हूँ। मैं निम्नलिखित लेख पढ़ रहा हूं: http://weblogs.asp.net/cibrax/default.aspx?PageIndex=3

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

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

       *-----------------* 
           * Database  * 
           *-----------------* 

           *------------------------* 
           * DAL(Data Access Layer) * 
           *------------------------* 

           *------------------------* 
           * BUL (Bussiness Layer) * 
           *------------------------* 
           *---------------* *-------------------* 
           * My OData stuff* * Internal API  * 
           *---------------* *-------------------* 

               *------------------* 
               * Web Application * 
               *------------------* 

, होगा यह काम करते हैं, या प्रदर्शन यह बेकार होगा:

एक smal ascii तस्वीर के साथ प्रदर्शित करने के लिए? या क्या मैं बस गेंद को याद कर रहा हूं? विचार यह है कि मैं OData WCF डेटा सेवा से BUL & DAL परत में जो भी तर्क संग्रहीत किया जाता है उसका पुन: उपयोग करना चाहता हूं।

मैं नए वर्गों है कि Data.Services नाम स्थान में EntityModel वर्गों से विरासत और एक नया DataService उद्देश्य यह है कि BUL & दाल & एपीआई परतों के लिए सभी कॉल के निशान बनाने बनाने के बारे में सोच रहा था। हालांकि मुझे यकीन नहीं है कि संसाधन बनाने और हटाने के अनुरोधों को कहां/किससे रोकना है।

मुझे उम्मीद है कि यह स्पष्ट है कि मैं क्या समझाने की कोशिश कर रहा हूं, और मुझे उम्मीद है कि कोई इस पर मेरी सहायता कर सकता है।

Answer 1

शैतान विवरण में है, लेकिन ऐसा लगता है कि जिस डिजाइन को आप प्रस्तावित कर रहे हैं वह काम करना चाहिए।

डेटा सेवा क्लास वह जगह है जहां आप सभी को कॉन्फ़िगरेशन सेटिंग्स को परिभाषित करने के लिए, कॉन्फ़िगरेशन सेटिंग्स और कस्टम ऑपरेशंस को परिभाषित करते हैं। इस परिदृश्य में, मुझे लगता है कि आप इसके बजाय डेटा संदर्भ (डेटा सेवा में 'टी') पर अधिक ध्यान केंद्रित करेंगे।

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

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

दो जगहें हैं जहां आप एक प्रकार की वस्तुओं से दूसरे में 'कूद' सकते हैं। एक GetResource() API में है, जहां आपको DQuery इकाइयों की अवधि में संभवतः एक IQueryable मिलता है। दूसरा ResolveResource() में है, जहां रनटाइम एक ऑब्जेक्ट को धारावाहिक करने के लिए कह रहा है, जैसे कि यह एक IQueryable से प्राप्त होगा, इसलिए यह संभवतः एक डीएएल इकाई भी है।

उम्मीद है कि यह मदद करता है - गैर वर्दी एपीआई पर समान पहुंच करना मुश्किल हो सकता है, लेकिन अक्सर इसके लायक है!