ما مدى قابلية LINQ للتوسع؟[مغلق]
https://stackoverflow.com/questions/214233
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنتجت المحادثات الأخيرة مع الزملاء وجهات نظر مختلفة حول هذه المسألة.ماذا تقولون يا أعضاء SO؟
أعلم أنه حتى مفهوم قابلية التوسع يمكن تناوله بعدة طرق وسياقات مختلفة، لكن ذلك كان جزءًا من المناقشة عندما تم طرح هذا الأمر.يبدو أن الجميع لديهم وجهة نظر مختلفة حول ما تعنيه قابلية التوسع حقًا.أشعر بالفضول لرؤية التباينات هنا أيضًا.في الواقع، لقد نشرت أ سؤال فقط لهذا المفهوم.
المحلول
وأود أن أعتقد أن أفضل وسيلة للتحقق هي عن طريق كتابة المعايير، ولكن في رأيي LINQ لديه إمكانية لتحسينات رمز الكتابة باليد مماثل لا. أنا لا أعرف جيدا كيف يستفيد من تلك حتى الان.
وLINQ تمكنك من التعبير عما تريد، وليس كيفية توليد ذلك. ميزة واحدة واضحة هي أن LINQ غير موازاة تلقائيا (انظر PLINQ ).
وهناك ميزة أخرى لLINQ هو أنه كسول، حتى تتمكن من إجراء عمليات حسابية، مستفيدة من جمع حسب الحاجة. هل يمكن تسليم رمز ما يعادلها، ولكن قد يكون من الأسهل بكثير للحصول على الحق في LINQ.
نصائح أخرى
في الاختبارات التي أجريناها، كان LINQ للكائنات (ForEach) أبطأ بحوالي 2x من حلقة foreach.
LINQ إلى SQL (قاعدة بيانات MS SQL) تقريبًا 10x أبطأ من الاستعلام المباشر باستخدام قارئ البيانات ، باستخدام معظم الوقت إنشاء SQL من شجرة التعبير (لذلك ، ستكون محدودًا في وحدة المعالجة المركزية وستكون قاعدة البيانات خمولًا) لتجنب ذلك ، يجب عليك استخدام الاستعلامات المترجمة.
انظر الى هذا للمزيد من.لا تزال معظم المعلومات الواردة في المنشور صالحة مع .NET 3.5 SP1.
وهذا السؤال هو قليلا كمن يسأل "كيف قابلة للتطوير هي مجموعات؟"
ودعونا نتحدث فقط عن LINQ إلى الكائنات. وبصفة عامة، لدرجة أن معظم تطبيقات IEnumerable<T> تكرار عبر كل عنصر في مجموعة الأساسي، LINQ لديها امكانات كبيرة لتوسيع نطاق سيئة. إنشاء List<Foo> التي تحتوي على عشرة ملايين العناصر وشيء من هذا القبيل:
var list = from Foo f in fooList
where f.Value = "Bar"
select f;
وستكون بطيئة. ولكن هذا في الحقيقة ليست خطأ LINQ ل. أنت الوحيد الذي أعطاه قائمة من عشرة ملايين قطعة.
ويمكنك التعامل مع هذا بنفس الطريقة التي تريد التعامل معها إذا LINQ لم تكن موجودة: من خلال بناء معاجم وSortedLists ومثل أن تساعدك على خفض حد فضاء البحث
وLINQ يمكن <م> تحسين التدرجية (حسنا، وجعل قابلية أسهل للوصول الى) عن طريق تنفيذ الاستعلام المؤجلة. يمكنك استبدال طريقة ساذجة مما يخلق القائمة، مرشحات لقائمة جديدة، فلاتر أن لائحة جديدة، وما إلى ذلك مع سلسلة من الاستفسارات LINQ:
var list1 = from Foo f in fooList where f.Value1 = "Bar" select f;
var list2 = from Foo f in list1 where f.Value2 = "Baz" select f;
var list3 = from Foo f in list2 where f.Value3 = "Bat" select f;
ويتم تنفيذ كل منها أكثر من مسار واحد من خلال جمع الأساسي عندما (وإذا) يصبح من الضروري تكرار عبر القائمة النهائية. مرة أخرى، على الرغم من هذا ليس شيئا جديدا: إذا لم يكن لديك LINQ، ربما كنت في نهاية المطاف استبدال طريقة ساذجة مع واحد أن فعلوا الشيء نفسه. لكن LINQ يجعل من الأسهل كثيرا.
في رأيي، يهدف LINQ إلى تبسيط الأمور من وجهة نظر التطوير، وليس معالجة قابلية التوسع.
في الواقع، استخدام LINQ يجعل الأمور سهلة للغاية عن طريق إخفاء الكثير من التعقيدات تحت الأغطية، وهذا هو الحال استطاع الرصاص عند استخدامه بشكل غير مسؤول, ، لقضايا قابلية التوسع.
والأمثلة كثيرة في الإجابات الأخرى، ولكن نذكر أهمها:
إذا كنت تقوم بالاستعلام عن مجموعة كائنات، فلا يمكنك تجاهل حجمها.ربما بدا القيام بذلك في النموذج، باستخدام LINQ، أمرًا جيدًا عندما كان هناك عدد قليل من الكائنات للاستعلام عنها...ولكن مع نمو الحجم، يصبح من الواضح أن الاستعلام يجب أن يحدث في قاعدة البيانات، وليس في النموذج.
إذا كنت تقوم بإنشاء SQL تلقائيًا باستخدام LINQ، على حد علمي، فلن تتمكن من إعطاء تلميحات لقاعدة البيانات الخاصة بك حول كيفية تجميع الاستعلامات، على سبيل المثال
WITH (NOLOCK).مع نمو أحجام طاولتك، تعد القدرة على معالجة هذه المشكلات أمرًا ضروريًا.مشابه لما سبق، ولكن ربما أكثر عمومية:عندما تقوم بمعالجة مشكلات قابلية التوسع عبر قاعدة بيانات، فإنك يجب أن التحكم في ما تفعله قاعدة البيانات.إن امتلاك لغة يتم ترجمتها إلى SQL، والتي يتم ترجمتها بعد ذلك مرة أخرى إلى خطة التنفيذ، يزيل التحكم من يديك.
ماذا يحدث إذا كان عليك تغيير مخطط قاعدة البيانات الخاصة بك لجعله أكثر قابلية للتطوير وكان الكود الخاص بك مرتبطًا به بقوة لأنه ليس لديك إجراءات مخزنة؟
على الرغم من أن الأمر يبدو بسيطًا، إلا أنه لا يمكنك تغيير مزود LINQ دون الكثير من الألم:الاستعلام عن SQL Server ليس مثل الاستعلام عن كائن أو الاستعلام عن XML.بالرغم من ذلك، فإن LINQ مشابه جدًا.أتوقع أن يبدأ بعض المطورين المبتدئين في "LINQ فورة" لأنه أسهل من تعلم كيفية القيام بالأشياء مع وضع قابلية التوسع في الاعتبار.
في الختام، أعتقد أنه من الممكن كتابة تعليمات برمجية قابلة للتطوير باستخدام LINQ، ولكن فقط من خلال استخدامها بعناية جيدة.لا يوجد قاتل أدوات, ، القاتل الوحيد شفرة.
وهذا يعتمد إلى حد كبير على أي مزود LINQ كنت تستخدم وكيف يتم استخدامه. LINQ ربما لا نعرف على سرعة التنفيذ مذهلة ولكن بدلا يوفر للمطورين مع إنتاجية أفضل بكثير.
ووفقا ل<لأ href = "http://blogs.msdn.com/ricom/archive/2007/07/05/dlinq-linq-to-sql-performance-part-4.aspx" يختلط = "نوفولو noreferrer "> كان هذا الرابط حتى مع بعض من هذه البرامج LINQ إلى SQL بالفعل أفضل من استخدام SQL المباشر في بعض الحالات.
إذا كنت تشعر بالقلق مع السرعة وتستخدم LINQ إلى كائنات الكثير هنا هو مشروع كود بلاكس ( على ما أظن) لمزود التي يمكن أن تعطيك 1000X تحسينات في الأداء.
وسؤالك حول قابلية في بعض الطرق يعتمد على ما كنت تستخدم LINQ ل. في تطبيقات الأعمال، وأنت لن تجد الكثير من أوامر SQL يتم تنفيذه - بطيئة they're ووالتي سيتم تجميعها في DBMS. ما سترى بدلا من ذلك الكثير من المكالمات الإجراء المخزن. وسوف تكون هذه أسرع قليلا في LINQ.
ونضع في اعتبارنا أن LINQ إلى SQL وما شابه ذلك مبنية على TOP من ADO.NET - أنها ليست منهجية مختلفة تماما أو أي شيء. بالتأكيد، سوف LINQ إلى XML استخدام واجهات برمجة التطبيقات المختلفة تحت الأغطية. وسيكون هذا يشبه إلى حد كبير مترجم - هناك دائما بعض التحسينات يمكن للانسان ان يجعل ذلك قد يكون أسرع، ولكن بالنسبة للجزء الأكبر، وهذه واجهات برمجة التطبيقات تكون قادرة على توليد أسرع وأقل كود عربات التي تجرها الدواب من التعليمات البرمجية التي تكتب لنفسك
وعلى صعيد التوسع خارج، يمكنك دائما وضع LINQ وراء خدمة الإنترنت إذا كنت ترغب في توزيع البيانات الخاصة بك قليلا أو يمكنك استخدام النسخ المتماثل الخادم SQL. لا ينبغي أن يكون أي أقل من تحجيم ADO.NET سيكون.
والتدرجية والأداء هما شيئان مختلفان ولكنها ذات صلة. إذا كنت ترغب في قياس الأداء، تحتاج إلى معرفة عدد المستخدمين (على سبيل المثال) التي يمكن أن تدعم مع مربع واحد. عند قياس قابلية إضافة مربع آخر ونرى ما اذا كان يمكن أن تدعم ضعف المبلغ الأصلي؟ لا يحتمل، وكنت قد فقط إضافة 75٪ إلى قوة المعالجة، واحدة المقبل يضيف 50٪ فقط من وحدة الأصل، وذلك تنخفض إلى الصفر سريع جدا. بغض النظر عن عدد صناديق إضافة على هذا المعدل، كنت محظوظا لمضاعفة عدد المستخدمين دعم الخاصة بك. هذا تطويره.
وكيف ينق جداول الوحدة النمطية الخاص بك ربما يعتمد أكثر على قاعدة البيانات، مدى قوة الجهاز هو، ما هو تصميم قاعدة البيانات، ما هو تصميم التطبيق الخاص بك.
وأنت كثيرا ما نرى المعايير الدقيقة التي من المفترض أن تكشف عن شيء قاطع، لكنها لم تفعل لأنها مجرد الرئيسي عرض حفرة للمشكلة برمتها.
ويمكنك سحب حسن البالغ من العمر 20/80 سبيل المثال هنا. من المحتمل أن يكون 20٪ عن الأداة و80٪ عن جميع أنواع الأشياء الملموسة التي تشكل التطبيق الخاص بك.
إذا كنت تبحث عن واقع الحياة المثال، يستخدم ستاكوفيرفلوو ينق بشكل كبير، وتحقق هذا / بودكاست.
وهناك ثمن للتخزين المؤقت والتحميل الكائنات على الطلب باستخدام LINQ إلى SQL الإطار. إذا كان كائن يمكن أجزاء كسول الحمل في حد ذاته على الطلب، فمن المحتمل جدا أن هناك إشارة إلى سياق البيانات داخل كل كائن. أيضا بتخزين بالمناسبة هذا السياق البيانات كل الكائن المطلوب من أي وقت مضى منه. مما يعني أنه إذا واصلتم واحدة من الأشياء الخاصة بك حول (إما في ذاكرة التخزين المؤقت أو لمجرد استخدامه لاحقا)، وأنت لا يحمل إلا على هذا الكائن، ولكن كل الكائن المطلوب من أي وقت مضى من سياق البيانات. لن تحصل على القمامة جمعت هذه لأن لا يزال يجري الرجوع إليها.
وهذه ليست مشكلة إذا كان كل من أهدافك لديهم عمر قصير، وتطبيق يخلق DataContexts جديد في كل مرة يفعل عمل جديد. ولكن أستطيع أن أرى كيف يمكن أن يخلق القضايا التدرجية، وإذا كان شخص ما لا يعلم شيئا عن الرهن إضافية ركوب جنبا إلى جنب مع كل كائن.
وينق هو scalabile بطرق عديدة.
وأحد الجوانب هو مواصفات التنفيذ وراء LINQ، والذي يسمح التعبير إلى أن تفسر إلى نفاد العملية، في لغة مختلفة (مصمم الرسم Linq2SQL، Linq2Hibernate)، أو في invironment الحوسبة الموزعة مثل مجموعة خريطة الحد لهذه المسألة ( DryadLINQ )
وثمة جانب آخر هو أن دلالات LINQ يوفر للغة. يمكنك تكرار خلال المليارات من الأشياء من دون ملء جمع في الذاكرة إذا كان مزود يدعم تحميل المؤجل أو يمكنك paralellize أو تحسين الاستعلام (PLINQ أو i4o).
