.NET और डेटाबेस परत

Question

जब मैंने प्रोग्रामिंग में पिछली बार काम किया, तो हम ऑब्जेक्ट रिलेशनल मैपिंग (ओआरएम) की ओर DataReaders और पारंपरिक ADO.NET API से दूर जाने की कोशिश कर रहे थे।

ऐसा करने के लिए, हमने sqlmetal के माध्यम से हमारे डीबी के DataContext उत्पन्न किए। तब एक पतली डेटा परत थी जिसने DataContextprivate बनाया, और डेटाबेस तक पहुंचने के लिए आवश्यक किसी भी कोड को इस पतली डेटा परत में public विधि का उपयोग करना होगा। इन तरीकों को मूल रूप से संग्रहीत प्रक्रियाएं थीं; वे LINQ से SQL के माध्यम से डेटाबेस पर क्वेरी करेंगे।

क्या आज यह एक आम दृष्टिकोण है? मेरा मतलब है, क्या हर कोई जिसका .NET 3.5 ढांचा का उपयोग वास्तव में अपनी निर्माण प्रक्रिया में वर्गमीटर चला रहा है, या क्या? यह लगभग उस समय एक हैक की तरह लग रहा था।

असल में, मैं जानना चाहता हूं कि LINQ से SQL और sqlmetal क्या उम्मीद करनी है यदि मैं एक .NET 3.5 दुकान पर आज एक डीएएल लिखने जा रहा हूं जो किसी तृतीय पक्ष, ओपन- स्रोत ओआरएम।

Answer 1

आपका दृष्टिकोण अच्छा है। मैं वर्तमान में एस्ट्रोरिया सेवाओं का उपयोग करता हूं (ADO.NET Data Services)। इसके बारे में MSDN Magazine में एक अच्छा परिचय था।

मुझे भी नया PLINQO पसंद है (हालांकि CodeSmith Tools की आवश्यकता है)। यह मेरी राय में बहुत चालाक है।

जब मेरे पास ऐसी डीएएल (सेवा परत) है, तो मैं बस अपने क्लाइंट एप्लिकेशन (सिल्वरलाइट या एएसपी.नेट एमवीसी) से इस सेवा का उपभोग करता हूं।

Answer 2

मुझे लगता है कि यह आपके उपयोग पर निर्भर करता है लेकिन मैं ऐसी पतली डेटा परत के साथ कहूंगा जैसा कि आपने समझाया है कि आपका डीएएल होगा। अधिकतर परियोजनाएं मुख्य रूप से संपादन/तर्क तर्क के लिए और शायद कुछ सिलाई तर्क प्राप्त करने के लिए शीर्ष पर एक और परत बनाती हैं।

मेरी अधिकांश परियोजनाओं के लिए मैं इसे इस तरह डिज़ाइन करता हूं।

भंडार DataContext के कहने रखती है और उजागर करता है कुछ बुनियादी जोड़ें/तरीकों को नष्ट
ProductRepository: भंडार सामान्य प्रश्नों (IQueryable)
StoreService ProductRepository, SalesRepository की तरह अलग अलग खजाने का एक उदाहरण का उपयोग करता है और की तरह कुछ बनाने के लिए सभी तर्क संभालती को उजागर करता है एक उत्पाद।

तो कुछ की तरह

...

StoreService.CreateProduct(/* properites */) 

इस परिणाम वर्ग के कुछ प्रकार लौट आते हैं।

Answer 3

यह अभी भी कुछ प्रकार की डेटा एक्सेस परत रखने के लिए सबसे अच्छा अभ्यास माना जाता है। चाहे यह एक ओआरएम के साथ सबसे अच्छा हासिल किया गया है, एक भारी बहस मुद्दा है। एक गुट है जो आम तौर पर तर्क देता है कि ओआरएम जाने का रास्ता है। एक अन्य गुट का तर्क है कि संग्रहीत प्रक्रियाओं और डेटाबेस केंद्रित सबसे अच्छा मार्ग है।

इसके अलावा, इस वास्तव में पोस्टर आप मतलब नहीं हो सकता है, लेकिन यह इसी तरह (और यह भी मेरे कक्ष में एक) है कि आप के रूप में

http://download.microsoft.com/download/4/a/3/4a3c7c55-84ab-4588-84a4-f96424a7d82d/NET35_Namespaces_Poster_LORES.pdf

Answer 4

यह बहुत साइट एसक्यूएल करने के लिए LINQ का उपयोग करता है, तो ले मर्जी।

आधिकारिक तौर पर, माइक्रोसॉफ्ट नए विकास के संदर्भ में LINQ से SQL पर Entity Framework का समर्थन कर रहा है। हालांकि, ऐसे लोगों का मुखर समूह है जो EF is the wrong way to go सोचते हैं। LINQ से SQL कुछ समय के लिए अभी भी आसपास रहेगा, और यह एक बहुत ही सभ्य ओआरएम है, अगर कुछ हद तक सीमित है जिसके तहत आप डीबी बैकएंड का उपयोग कर सकते हैं।

मैं LINQ को आपके ORM के लिए एक महान प्रारंभिक बिंदु के रूप में अनुशंसा करता हूं। यदि आपको बेहतर की आवश्यकता है, तो ईएफ और/या NHibernate देखें।

Answer 5

"क्या आज यह एक आम दृष्टिकोण है? मेरा मतलब है, क्या हर कोई .NET 3.5 ढांचे का उपयोग कर रहा है वास्तव में अपनी निर्माण प्रक्रिया में वर्गमीटर चला रहा है, या क्या?"

जिन लोगों को मैं 3.5 फ्रेमवर्क (और यह केवल हर किसी के बारे में) का उपयोग कर जानता हूं - विशाल बहुमत - अभी भी एनएचबेर्नेट का उपयोग कर रहे हैं। संस्करण 2.0 एक बहुत अच्छा या/एम है। मैंने इसे हालिया प्रोजेक्ट पर इस्तेमाल करना शुरू कर दिया है और यह मेरे डेटा एक्सेस कोड को काफी हद तक कम कर देता है, उस बिंदु पर जहां मैं वास्तव में भविष्य में किसी और चीज का उपयोग नहीं करना चाहता हूं। और फ्लुएंट एनएचबर्ननेट एपीआई उन लोगों के लिए कुछ रास्ता बना रहा है जो एक्सएमएल मैपिंग पसंद नहीं करते हैं।

Answer 6

सर्वोत्तम डेटा परत वह है जो सादा और सरल है और किसी भी घंटों के बिना नौकरी पूरी हो जाती है। मैंने आपके द्वारा उल्लिखित तकनीकों का उपयोग किया है और यहां उनके बारे में लिखा है: The Only Pattern for Data Access is - There Are No Patterns for Data Access