2009-02-27 18 views
19

मैंने अभी मध्य आकार के प्रोजेक्ट पर LINQ से SQL का उपयोग करना शुरू कर दिया है, और L2S ऑफ़र के फायदे के बारे में मेरी समझ में वृद्धि करना चाहता हूं।LINQ से SQL के फायदे क्या हैं?

मुझे लगता है कि एक नुकसान यह है कि यह कोड की एक और परत जोड़ता है, और मेरी समझ यह है कि संग्रहित प्रक्रियाओं और ADO.Net का उपयोग करने से इसकी धीमी कार्यक्षमता है। ऐसा लगता है कि डिबगिंग एक चुनौती हो सकती है, खासतौर से अधिक जटिल प्रश्नों के लिए, और ये किसी भी तरह से संग्रहीत प्रो में स्थानांतरित हो सकती है।

मैं हमेशा बेहतर विकास वातावरण में प्रश्न लिखने का एक तरीका चाहता हूं, क्या एल 2 एस उन समाधानों से पूछताछ करता है जिन्हें मैं ढूंढ रहा हूं? या हमने अभी एसक्यूएल के शीर्ष पर एक और परत बनाई है, और अब चिंता करने के लिए दोगुना है?

+0

मुझे लगता है कि यदि आप अपना प्रश्न बदलते हैं तो हर जगह "LINQ से SQL" कहने के लिए आप चीजों को स्पष्ट कर देंगे। LINQ से SQL तक बहुत सारे LINQ हैं। –

+0

अच्छा बिंदु, thx। – alchemical

उत्तर

41

लाभ L2S प्रदान करता है:

  • कोई जादू तार, जैसे आप एसक्यूएल में प्रश्नों
  • Intellisense
  • संकलित जाँच जब डेटाबेस
  • तेज़ विकास बदलता है
  • काम पैटर्न के यूनिट (संदर्भ)
  • ऑटो-जेनरेट की गई डोमेन ऑब्जेक्ट्स जो उपयोग योग्य हैं छोटी परियोजनाएं
  • आलसी लोडिंग।
  • लिनक्स प्रश्न/लैम्बडास लिखना सीखना एक .NET डेवलपर्स के लिए सीखना चाहिए।

प्रदर्शन के बारे में:

  • सबसे अधिक संभावना प्रदर्शन सबसे समाधान में एक समस्या होने के लिए नहीं जा रहा है। प्री-ऑप्टिमाइज़ करने के लिए एक विरोधी पैटर्न है। यदि आप बाद में देखते हैं कि आवेदन के कुछ क्षेत्रों को धीमा करना है, तो आप इन भागों का विश्लेषण कर सकते हैं, और कुछ मामलों में संग्रहित प्रक्रियाओं या ADO.NET के साथ कुछ linq प्रश्नों को भी स्वैप कर सकते हैं।
  • कई मामलों में आलसी लोडिंग सुविधा प्रदर्शन को तेज कर सकती है, या कम से कम कोड को सरल बना सकती है।

debuging के बारे में:

  • मेरी राय Linq2Sql debuging में दोनों संग्रहित प्रक्रियाओं और ADO.NET की तुलना में काफी आसान है। मैं अनुशंसा करता हूं कि आप Linq2Sql Debug Visualizer पर एक नज़र डालें, जो आपको क्वेरी देखने में सक्षम बनाता है, और डीबगिंग के परिणाम देखने के लिए निष्पादन को ट्रिगर भी करता है।
  • तुम भी कंसोल विंडो के लिए सभी एसक्यूएल प्रश्नों लिखने के संदर्भ में, अधिक जानकारी here

एक और परत के बारे में कॉन्फ़िगर कर सकते हैं:

  • Linq2Sql एक और परत के रूप में देखा जा सकता है, लेकिन यह एक पूरी तरह से डेटा पहुंच परत है। संग्रहीत प्रक्रिया कोड की एक और परत भी है, और मैंने कई मामलों को देखा है जहां व्यापार तर्क का हिस्सा संग्रहित प्रक्रियाओं में लागू किया गया है। यह मेरी राय में बहुत खराब है क्योंकि आप फिर व्यापार स्तर को दो स्थानों पर विभाजित कर रहे हैं, और डेवलपर्स के लिए व्यवसाय डोमेन का स्पष्ट दृश्य प्राप्त करना कठिन होगा।
+0

+1 बहुत अच्छा जवाब मुझे यह पसंद है, धन्यवाद। –

+1

अच्छा प्रत्यारोपण – AjayR

1

मुझे कहना होगा कि वे वही हैं जो आप खोज रहे हैं। इसमें कुछ समय लग रहा है, लेकिन एक बार ऐसा करने के बाद आप वापस जाने के बारे में सोच नहीं सकते (कम से कम मेरे लिए)। लिनक्स बनाम संग्रहीत प्रक्रियाओं के संबंध में, यदि आप इसे गलत बनाते हैं तो आप पर खराब प्रदर्शन हो सकता है। मैं लिनक में क्लाइंट की कुछ संग्रहीत प्रक्रियाओं को एसक्यूएल करने के लिए स्थानांतरित कर दिया गया था, जो बहुत ही कोड किए गए थे, इसलिए समय 20secs (वेब ​​ऐप के लिए पूरी तरह से अप्राप्य) से < 1 सेकंड तक गिरा दिया गया। और संग्रहीत प्रक्रिया समाधान के बाद बहुत कम कोड।

अद्यतन 1: इसके अलावा आपको बहुत लचीलापन मिलता है, क्योंकि आप जो भी प्राप्त कर रहे हैं उसके कॉलम को सीमित कर सकते हैं और यह वास्तव में केवल इसे पुनर्प्राप्त कर देगा। संग्रहीत प्रक्रिया समाधान पर आपको प्रत्येक कॉलम सेट के लिए एक प्रक्रिया को परिभाषित करना होगा, भले ही अंतर्निहित प्रश्न समान हों।

0

हमने हाल ही में एंटीटी फ्रेमवर्क पर्यावरण पर LINQ2Entity पर स्विच किया। इससे पहले, हमारे पास बुनियादी SQLadapters थे। चूंकि जिस डेटाबेस के साथ हम काम कर रहे हैं वह छोटा है, इसलिए मैं LINQ के प्रदर्शन पर टिप्पणी नहीं कर सकता।

मुझे यह स्वीकार करना होगा कि लेखन प्रश्न बहुत आसान हो गए हैं, और संस्थाओं के अतिरिक्त, मजबूत टाइपिंग सक्षम करता है।

+0

जोहान्स, मुझे नहीं लगता कि मजबूत टाइपिंग linq2entity बनाम linq2sql के लिए एक तर्क है, क्योंकि इसमें मजबूत टाइपिंग भी है :) ... मुझे यकीन है कि कुछ अच्छे हैं हालांकि, मैं linq2sql बनाम ado.net की तुलना करने के लिए सीमित हूं – eglasius

14

बस कुछ त्वरित विचार।

LINQ सामान्य

  • में स्मृति क्वेरी संग्रह और एक ही वाक्य रचना के साथ बाहर के प्रक्रिया डेटा स्टोर और ऑपरेटरों
  • एक कथात्मक शैली प्रश्नों के लिए बहुत अच्छी तरह से काम करता है में है - यह दोनों के लिए आसान है बहुत से मामलों में पढ़ें और लिखें
  • साफ भाषा एकीकरण नए प्रदाताओं (प्रक्रिया में और बाहर दोनों) को लिखा जा सकता है और उसी क्वेरी अभिव्यक्ति वाक्यविन्यास
का लाभ उठा सकता है

LINQ एसक्यूएल के लिए (या अन्य डेटाबेस LINQ)

  • लेखन प्रश्नों जहां संग्रहीत procs के रूप में करने के बजाय उन्हें जरूरत है एक बहुत तेजी से विकास करता है: वहाँ अब तक कम चरणों बस शामिल डेटा आप चाहते हैं पाने के लिए कर रहे हैं
  • बहुत कम स्ट्रिंग्स (संग्रहीत प्रोसेस, पैरामीटर नाम या सिर्फ सादे एसक्यूएल) शामिल हैं जहां टाइपो परेशान हो सकते हैं; इस सिक्का का दूसरा पक्ष यह है कि आपको अपनी क्वेरी
  • के लिए इंटेलिजेंस मिलता है जब तक आप ADO.NET से "कच्चे" डेटा के साथ काम नहीं करेंगे, तो आप कहीं भी ऑब्जेक्ट मॉडल के लिए जा रहे हैं। क्यों LINQ से SQL को आपके लिए इसे संभाल नहीं देते? मैं सिर्फ एक प्रश्न करने में सक्षम होने और उपयोग करने के लिए तैयार वस्तुओं को वापस पाने की तरह।
  • मैं प्रदर्शन को ठीक होने की उम्मीद करता हूं - और जहां यह नहीं है, आप इसे स्वयं ट्यून कर सकते हैं या सीधे SQL पर वापस आ सकते हैं। एक ओआरएम का उपयोग निश्चित रूप से सही इंडेक्स आदि बनाने की आवश्यकता को दूर नहीं करता है, और आपको आम तौर पर गैर-तुच्छ क्वेरी के लिए जेनरेट होने वाले एसक्यूएल की जांच करनी चाहिए।

यह किसी भी माध्यम से पैनसिया नहीं है, लेकिन मैं इसे एसक्यूएल प्रश्न सीधे या संग्रहित प्रोसेस का उपयोग करने के लिए पसंद करता हूं।

+0

जॉन और बेंग दोनों उत्कृष्ट विवरण के साथ, वही बात कहें! –

+0

शायद डीबी एसपी में व्यापार तर्क को लागू करना सबसे अच्छा है (इसलिए सुरक्षा और प्रदर्शन विश्लेषण के लिए डीबी क्षमताओं का उपयोग करने के लिए) और एसपी से प्राप्त डेटा के साथ ऑब्जेक्ट भरते समय कोडिंग को कम करने के लिए केवल LINQ का उपयोग करना। – Faiz

+1

@ फ़ैज़: दूसरी तरफ, व्यापार तर्क आमतौर पर एसक्यूएल से सी # में लागू करने के लिए काफी सरल * सरल है, और यदि आपके पास डेटा के लिए केवल एक ही पहुंच मार्ग है (उदाहरण के लिए डेटाबेस के सामने एक अच्छी तरह से स्तरित वेब सेवा) तो आप दोनों दुनिया के सर्वश्रेष्ठ प्राप्त कर सकते हैं। –

2

बस एक अद्यतन के रूप में, यहाँ एसक्यूएल करने के लिए LINQ के भविष्य पर कुछ लिंक कर रहे हैं:

What is the Future of Linq to SQL

Has Microsoft confirmed their stance on LINQ to SQL end-of-life?

Is LINQ to SQL Dead or Alive?

पिछले लिंक राज्यों में एक टिप्पणी के रूप में , LINQ से SQL दूर जाने वाला नहीं है, कम से कम माइक्रोसॉफ्ट द्वारा "बेहतर" पर नहीं। इन टिप्पणियों और पदों को जितना आप करेंगे, बस अपनी विकास योजनाओं में सावधान रहें।