क्या आप नई परियोजनाओं के लिए LINQ से SQL का उपयोग करेंगे?

Question

मैं जांच कर रहा हूं कि एक नई वेब-आधारित परियोजना के लिए किस डेटा परत का उपयोग करना है, मैं डिजाइन कर रहा हूं और मैं LINQ से SQL को शामिल करने के लिए बहुत उत्सुक हूं। इसकी स्पष्ट सादगी, लचीलापन और डिजाइनर समर्थन वास्तव में अपील करता है और SQL सर्वर के लिए अंतर्निहित टाई-इन ठीक है।

हालांकि, हाल ही में यह घोषणा की गई है कि LINQ से SQL एंटिटी फ्रेमवर्क में पिछली सीट ले जाएगा, जिसे अब एडीओ.NET टीम (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx) में भेज दिया गया है। निश्चित रूप से, यह भविष्य में समर्थित होगा, लेकिन यह संभावना नहीं है कि यह और अधिक विकास कार्य देखेंगे।

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

प्रोजेक्ट स्वयं एएसपी.नेट और एसक्यूएल सर्वर 2005/2008 आधारित है और संभवतः एमवीसी का उपयोग करेगा, भले ही यह अभी भी बीटा में है। यह एक निजी परियोजना है, डेटाबेस अत्यधिक जटिल नहीं होगा और इसका मुख्य रूप से .NET भविष्य तकनीक को देखने के लिए प्रोटोटाइप के रूप में उपयोग किया जाएगा। मैं भविष्य में परियोजनाओं को आधार पर रखूंगा जो मैं इस से सीखता हूं, इसलिए मेरे द्वारा चुने गए विकल्पों से आने वाले बड़े समाधान प्रभावित होंगे।

और हाँ, मुझे एहसास है कि माइक्रोसॉफ्ट शायद कल भी एक पूरी नई डेटा एक्सेस प्रौद्योगिकी लाएगा! ;)

Answer 1

खैर, यह ज्यादातर यहाँ जवाब (देखने के कुछ दिलचस्प अंक के रूप में अच्छी तरह से) पहले से ही में शामिल किया गया है, लेकिन मैं वैसे भी इसे फिर से कहने के लिए ..

एसक्यूएल (L2S) को LINQ बहुत बहुमुखी है जा रहा हूँ, लेकिन यह मेरे दृष्टिकोण से बहुत ताकत महसूस करता है। ज्यादातर मामलों में यह सरल चीजें करने में अच्छा काम करता है, लेकिन जैसे ही आप इसे थोड़ा और पूछते हैं, यह महंगा हो जाता है। यह बिल्कुल बुरी चीज नहीं है। मुझे वास्तव में लगता है कि LINQ से SQL वास्तव में इकाई फ्रेमवर्क को अच्छी तरह से आपूर्ति करता है।

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

मैं यह स्वीकार करने वाला पहला व्यक्ति हूं कि उत्पन्न टी-एसक्यूएल की गुणवत्ता के संदर्भ में एल 2 एस को एंटीटी फ्रेमवर्क पर लाभ है (मुझे चाहिए, चूंकि एल 2 एस विशेष रूप से SQL सर्वर से पूछताछ के लिए बनाया गया है) और अवधारणात्मक रूप से और symantically , LINQ से SQL का अधिकांश ईएफ के समान है, लेकिन जहां आप दीवार को हिट करते हैं, वह अधिक जटिल कार्यान्वयन आवश्यकताओं के लिए आवश्यकताओं और विचारों को विस्तारित करने पर है।

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

तो .. संक्षेप में .. मैं इसे इस प्रकार के दृष्टिकोण चाहते हैं:

क) LINQ सीखना (माइक्रोसॉफ्ट के ORM पैटर्न और प्रौद्योगिकी) के लिए एक परिचय के रूप में SQL करने के लिए ..यह आपको उन अधिकांश मौलिक सिद्धांतों से परिचित करता है जो एंटीटी फ्रेमवर्क के साथ साझा किए जाते हैं, और LINQ स्टाइल पूछताछ का स्वाद (यदि आपके पास टी-एसक्यूएल में पृष्ठभूमि है तो एक अधिग्रहित स्वाद)

बी) एक बार जब आपको मिल जाए LINQ से SQL पर संभाल लें, मैं अतिरिक्त लाभ (ईएसक्यूएल इत्यादि)

सी) में अवधारणा प्रोजेक्ट का सबूत लागू करने और परिणामों की तुलना करने के लिए एंटिटी फ्रेमवर्क पर कूदने की अनुशंसा करता हूं।

Answer 2

एनएचबेर्नेट चुनें। यह एक अवधारणा या वास्तविक ओआरएम के रूप में कुछ समय के लिए आसपास रहेगा। तो यह दोनों सीखना उपयोगी होगा।

Answer 3

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

Answer 4

सबसोनिक की जाँच करें:

http://subsonicproject.com/

Answer 5

मुझे लगता है कि EDM के लक्ष्यों को हमारे एसक्यूएल को LINQ की तुलना में बहुत बड़ा। यदि आप एक साधारण ओआरएम की तलाश में हैं तो मुझे लगता है कि LINQ से SQL को जाने का तरीका है। यदि आप कक्षाओं में निर्माण करने की योजना बना रहे हैं जिनके पास डेटाबेस टेबल के संबंध में विरासत संरचना है जिसमें एक रिलेशनल संरचना है और अन्य उन्नत मैपिंग करते हैं, तो ईडीएम एक अच्छा विकल्प हो सकता है।

Answer 6

आईएमओ, यह पूरी चीज वास्तव में अनुपात से बाहर उड़ा दी गई थी।

माइक्रोसॉफ्ट ने यह नहीं कहा कि LINQ से SQL होगा। उन्होंने अधिक संकेत दिया कि इसे इकाई फ्रेमवर्क में विलय कर दिया जाएगा।

मैं एक समाधान के रूप में इकाई फ्रेमवर्क का उपयोग करने पर ध्यान केंद्रित करता हूं, यह जानकर कि LINQ से SQL का अधिकांश इसमें शामिल होगा।

वैसे भी वास्तव में इतना अंतर नहीं है। सबसे बड़ी शिकायत यह है कि इकाई फ्रेमवर्क हल्के वजन नहीं है। क्या यह वास्तव में तब तक मायने रखता है जब तक आपके स्तर के बीच अच्छा अलगाव हो?

Answer 7

मैं इकोस्टॉर्म से सहमत हूं। एल 2 एस आपकी जरूरतों के लिए अच्छा है। और यह काम करना काफी आसान है ...

Answer 8

यह उल्लेखनीय है कि यह साइट LINQ से SQL का उपयोग करके बनाई गई है। जेफ ने स्टैक ओवरफ्लो पॉडकास्ट पर इसका इस्तेमाल करने के बारे में बात की।

Answer 9

एल 2 एस एक शानदार तकनीक है, और मैं कभी भी पुराने एडीओ पर वापस नहीं जाऊंगा।

लेकिन जैसा कि आपने बताया है, यह एल 2 ई में बैकसीट ले रहा है। एल 2 एस सक्षम से अधिक है और मैंने इसके साथ कई अनुप्रयोग किए हैं और अविश्वसनीय रूप से प्रसन्न हैं। लेकिन यह सुनकर कि यह अब मेरे पक्ष में चाकू लगाएगा। तो मैं एल 2 ई की जांच करने गया और यह लगभग समान बात है जब यह SQL इंटरैक्शन की बात आती है, और कई तरीकों से मुझे यह आसान लगता है, इसके संबंध हैंडलिंग के साथ अधिक कुशल नहीं है। ऐसी समानताओं के साथ, यह L2E चुनने के लिए तार्किक लगता है।

मैं स्विच कर और दो व्यवस्थाएं की तुलना पर एक पोस्ट ने लिखा है: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

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

Answer 10

यदि आप अपने ऐप को सही ढंग से डिज़ाइन करते हैं और अपनी डेटा एक्सेस लेयर को अच्छी तरह से अलग करते हैं, तो आपको L2S के साथ जाना चाहिए। जो मैंने आपकी पोस्ट से अनुमान लगाया है, उससे यह एक बड़ी परियोजना नहीं है, इसलिए एल 2 एस को आपकी आवश्यकताओं को पूरा करना चाहिए, जबकि सादा पुराना एडीओ.नेट सिर्फ एक नो-नो है, और इकाई फ्रेमवर्क है ... बस इसका इस्तेमाल न करें , ठीक? वैसे भी, यदि आप अपने डीएएल को अच्छी तरह से अलग करते हैं, तो भविष्य में यदि आप बढ़ते हैं तो भविष्य में आप एल 2 एस को कुछ और कर सकते हैं। और यहां तक ​​कि यदि एल 2 एस कहीं नहीं जा रहा है, तो यह कहीं भी नहीं जा रहा है। एमएस ने इसमें निवेश करना बंद कर दिया, लेकिन यह बहिष्कृत या कुछ नहीं बनने वाला है, इसलिए यह अभी भी एक सुरक्षित निवेश है। वैकल्पिक रूप से, आपको NHibernate का मूल्यांकन करना चाहिए, जो कि सरल और परिपक्व है।

Answer 11

मैं अपने वर्तमान वेब प्रोजेक्ट पर एल 2 एस का भारी उपयोग करता हूं और मेरा मानना ​​है कि आपको मिलेगा सबसे बड़ा लटकाना एन-स्तरीय डेटाबेस विकास करने का सबसे अच्छा तरीका है।

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

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

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

public static void UpdateUser(UserLibrary.User user) { 
     using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr)) 
     { 
      UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault(); 
      newUser.Email = user.Email; 
      newUser.FirstName = user.FirstName; 
      newUser.LastName = user.LastName; 
      dc.SubmitChanges(); 
     }   

आप बस एक उपयोगकर्ता एक अलग DataContext में बनाया में गुजरती हैं और काम करने के लिए अद्यतन, जब तक आप DataContext.ObjectTrackingEnabled = false है, जो मैं सिफारिश नहीं होगा सेट उम्मीद नहीं कर सकते। इसके बजाय, उसी डेटाकॉन्टेक्स्ट के भीतर आपको मौजूदा ऑब्जेक्ट को पुनर्प्राप्त करना चाहिए, इसके मान अपडेट करें, फिर उस परिवर्तन सबमिट करें। सभी डेटा कॉन्टेक्स्ट के भीतर कार्यों की तरह रखें।

मैं एल 2 एस की सिफारिश करता हूं, हालांकि, जब आप कुछ निगलने वाले मुद्दों (ऊपर की तरह) प्राप्त करते हैं, तो यह एक महान तकनीक है और निश्चित रूप से एक समय बचतकर्ता है। हालांकि मैं आपके डीएएल के चारों ओर एक पतली आवरण करने की सिफारिश करता हूं, ताकि आप आसानी से बदल सकें। मैं अपने डेटा के एक हिस्से के लिए ओपनएप ओआरएम -> माईएसक्ल का उपयोग करने के लिए अपने कोड के एक हिस्से को पोर्ट करने के लिए (आर्थिक कारणों से) पर विचार कर रहा हूं, और एक उचित ढंग से परिभाषित परत के साथ, यह कार्य केवल मुझे कुछ घंटों तक लेना चाहिए।