أداء Linq للكيانات مقابل ESQL

Question

عند استخدام Entity Framework، هل أداء ESQL أفضل من Linq to Entities؟

أفضل استخدام Linq to Entities (بشكل أساسي بسبب فحص النوع القوي)، لكن بعض أعضاء فريقي الآخرين يستشهدون بالأداء كسبب لاستخدام ESQL.أرغب في الحصول على فكرة كاملة عن إيجابيات/سلبيات استخدام أي من الطريقتين.

Answer 1

الاختلافات الأكثر وضوحا هي:

Linq to Entities عبارة عن كود مكتوب بقوة بما في ذلك بناء جملة لطيف لفهم الاستعلام.حقيقة أن كلمة "من" تأتي قبل كلمة "تحديد" تسمح لـ IntelliSense بمساعدتك.

يستخدم Entity SQL الاستعلامات التقليدية المستندة إلى سلسلة مع SQL أكثر شيوعًا مثل بناء الجملة حيث تأتي عبارة SELECT قبل FROM.نظرًا لأن eSQL يعتمد على السلسلة، فقد يتم تكوين الاستعلامات الديناميكية بطريقة تقليدية في وقت التشغيل باستخدام معالجة السلسلة.

الفرق الرئيسي الأقل وضوحًا هو:

يتيح لك Linq to Entities تغيير الشكل أو "عرض" نتائج استعلامك إلى أي شكل تحتاجه باستخدام الزر "select new{...}" بناء الجملة.الأنواع المجهولة، الجديدة في C# 3.0، سمحت بذلك.

لا يمكن الإسقاط باستخدام Entity SQL حيث يجب عليك دائمًا إرجاع ObjectQuery<T>.في بعض السيناريوهات، من الممكن استخدام ObjectQuery<object> ولكن يجب عليك التغلب على حقيقة أن .Select يقوم دائمًا بإرجاع ObjectQuery<DbDataRecord>.انظر الكود أدناه...

ObjectQuery<DbDataRecord> query = DynamicQuery(context,
        "Products",
        "it.ProductName = 'Chai'",
        "it.ProductName, it.QuantityPerUnit");

public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
    ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
    ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
    ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
    return result;
}

هناك اختلافات أخرى أكثر دقة وصفها أحد أعضاء الفريق بالتفصيل هنا و هنا.

Answer 2

يمكن لـ ESQL أيضًا إنشاء بعض قواعد SQL الشريرة بشكل خاص.اضطررت إلى تتبع مشكلة مع مثل هذا الاستعلام الذي كان يستخدم الفئات الموروثة واكتشفت أن ESQL الصغير الخاص بي المكون من 4 أسطر قد تمت ترجمته في بيان SQL ضخم مكون من 100000 حرف.

فعلت نفس الشيء مع Linq وأصبح الكود المترجم أكثر قابلية للإدارة، دعنا نقول 20 سطرًا من SQL.

بالإضافة إلى ما ذكره أشخاص آخرون، فإن Linq من النوع القوي، على الرغم من أنه مزعج للغاية عند تصحيح الأخطاء بدون ميزة التحرير والمتابعة.

إعلان

Answer 3

يتيح لك Entity-SQL (eSQL) القيام بأشياء مثل الاستعلامات الديناميكية بسهولة أكبر من LINQ للكيانات.ومع ذلك، إذا لم يكن لديك سيناريو يتطلب eSQL، فسأكون مترددًا في الاعتماد عليه عبر LINQ لأنه سيكون من الصعب جدًا صيانته (على سبيل المثال.لا مزيد من التحقق من وقت الترجمة، وما إلى ذلك).

أعتقد أن LINQ يسمح لك بترجمة استعلاماتك مسبقًا أيضًا، مما قد يمنحك أداءً أفضل.ريكو مارياني تم تدوينه حول أداء LINQ منذ فترة ويناقش الاستعلامات المجمعة.

Answer 4

رسم بياني جميل يوضح مقارنات الأداء هنا: استكشاف أداء إطار الكيانلا يوجد اختلاف كبير بين ESQL والكيانات ولكن الاختلافات الشاملة مهمة في استخدام الكيانات على الاستعلامات المباشرة

يستخدم Entity Framework طبقتين من تعيين الكائنات (مقارنة بطبقة واحدة في LINQ إلى SQL)، والتعيين الإضافي له تكاليف أداء.على الأقل في الإصدار 1 من EF، يجب على مصممي التطبيقات اختيار Entity Framework فقط إذا كانت إمكانات النمذجة ورسم خرائط ORM يمكن أن تبرر هذه التكلفة.

Answer 5

إن المزيد من التعليمات البرمجية التي يمكنك تغطيتها من خلال التحقق من وقت الترجمة بالنسبة لي هو شيء سأضعه أعلى من الأداء.بعد قولي هذا، في هذه المرحلة، ربما أميل نحو ESQL ليس فقط بسبب الأداء، ولكنه أيضًا (في الوقت الحاضر) أكثر مرونة فيما يمكنه القيام به.ليس هناك ما هو أسوأ من استخدام حزمة تقنية لا تحتوي على ميزة تحتاجها حقًا.

لا يدعم إطار عمل الكيان أشياء مثل الخصائص المخصصة والاستعلامات المخصصة (عندما تحتاج إلى ضبط الأداء حقًا) ولا يعمل بنفس طريقة linq-to-sql (على سبيل المثال.هناك ميزات لا تعمل ببساطة في إطار عمل الكيان).

انطباعي الشخصي عن Entity Framework هو أن هناك الكثير من الإمكانات، ولكن من المحتمل أن يكون "صارمًا" قليلاً في تنفيذه لاستخدامه في بيئة الإنتاج في حالته الحالية.

Answer 6

للاستعلامات المباشرة أستخدم linq للكيانات، للاستعلامات الديناميكية أستخدم ESQL.ربما الجواب ليس إما/أو، ولكن و/أيضًا.