.net ماهي - إطار الكيان مقابل LINQ إلى SQL




تقنية entity (15)

الآن تم إصدار .NET v3.5 SP1 (مع VS2008 SP1) ، لدينا الآن إمكانية الوصول إلى إطار عمل .NET framework.

سؤالي هو هذا. عند محاولة تحديد ما بين استخدام Entity Framework و LINQ إلى SQL كمرجع ORM ، ما الفرق؟

الطريقة التي أفهمها ، إطار الكيان (عند استخدامها مع LINQ إلى الكيانات) هو "الأخ الأكبر" ل LINQ إلى SQL؟ إذا كان هذا هو الحال - ما هي مزاياها؟ ماذا يمكن أن تفعل ذلك LINQ إلى SQL لا تستطيع أن تفعل من تلقاء نفسها؟


Answers

وقد غطت الإجابات هنا العديد من الاختلافات بين Linq2Sql و EF ، ولكن هناك نقطة رئيسية لم تحظ باهتمام كبير: Linq2Sql يدعم SQL Server فقط بينما لدى EF موفري RDBMS التالية:

مقدمة من Microsoft:

  • ADO.NET السائقين ل SQL Server ، OBDC و OLE DB

عبر مزودي الطرف الثالث:

  • الخلية
  • وحي
  • DB2
  • VistaDB
  • سكليتي
  • كيو
  • ينفورميكس
  • U2
  • سايبيس
  • Synergex
  • فايربيرد
  • Npgsql

على سبيل المثال لا الحصر.

وهذا يجعل EF تجريدًا فعالًا للبرمجة على مخزن البيانات العلائقية ، مما يعني أن المطورين لديهم نموذج برمجة ثابت للعمل مع بغض النظر عن مخزن البيانات الأساسي. قد يكون ذلك مفيدًا للغاية في الحالات التي تقوم فيها بتطوير منتج تريد التأكد من أنه سيتفاعل مع مجموعة واسعة من أجهزة RDBMS الشائعة.

هناك موقف آخر يكون فيه هذا التجريد مفيدًا حيث تكون جزءًا من فريق تطوير يعمل مع عدد من العملاء المختلفين ، أو وحدات أعمال مختلفة داخل المؤسسة ، وترغب في تحسين إنتاجية المطورين من خلال تقليل عدد أجهزة RDBMS التي يجب أن تصبح مألوفة لدعم مجموعة من التطبيقات المختلفة على قمة RDBMS المختلفة.


كانت تجربتي مع Entity Framework أقل من ممتازة. أولا ، عليك أن ترث من الطبقات الأساسية EF ، لذلك أقول وداعا ل POCOs. يجب أن يكون التصميم الخاص بك حول EF. مع LinqtoSQL يمكنني استخدام كائنات الأعمال الحالية الخاصة بي. بالإضافة إلى ذلك ، لا يوجد تحميل بطيء ، يجب عليك تنفيذ ذلك بنفسك. هناك بعض العمل هناك لاستخدام POCOs وتحميل البطيئة ، لكنها موجودة IMHO لأن EF ليست جاهزة بعد. أخطط للعودة إليها بعد 4.0


انطباعي هو أن قاعدة البيانات الخاصة بك جميلة للغاية أو سيئة للغاية إذا كان Linq2Sql لا تناسب احتياجاتك. لدي حوالي 10 مواقع على حد سواء أكبر وأصغر باستخدام Linq2Sql. لقد نظرت والإطار الكيان عدة مرات ولكن لا أجد سببا جيدا لاستخدامه على Linq2Sql. قال أن أحاول استخدام قواعد البيانات الخاصة بي كنموذج لذلك لدي بالفعل 1 إلى 1 بين النموذج وقاعدة البيانات.

في وظيفتي الحالية لدينا قاعدة بيانات مع 200+ الجداول. قاعدة بيانات قديمة تحتوي على الكثير من الحلول السيئة لذلك يمكنني رؤية ميزة Entity Framework على Linq2Sql لكن ما زلت أفضّل إعادة تصميم قاعدة البيانات لأن قاعدة البيانات هي محرك التطبيق وإذا كانت قاعدة البيانات مصممة بشكل سيئ وبطيء ثم تطبيقي سيكون بطيئا أيضا. إن استخدام إطار الكيان في قاعدة بيانات كهذه يبدو كأنه إصلاح سريع لإخفاء النموذج السيئ ، لكنه لا يمكن أن يخفي الأداء السيئ الذي تحصل عليه من قاعدة البيانات هذه.


أعمل مع العميل الذي يحتوي على مشروع كبير يستخدم Linq-to-SQL. عندما بدأ المشروع كان الخيار الواضح ، لأن Entity Framework كان يفتقر إلى بعض الميزات الرئيسية في ذلك الوقت وكان أداء Linq-to-SQL أكثر سرعة.

لقد تطورت EF الآن وتفتقر شركة Linq-to-SQL إلى ميزة رئيسية لخدمات قابلة للتحجيم بشكل كبير ، وهذا هو الدعم لعمليات التزامن. لدينا أكثر من 100 طلب في الثانية في بعض الأحيان ، وعلى الرغم من أننا قمنا بتحسين قواعد البيانات الخاصة بنا ، إلا أن معظم الاستفسارات تستغرق عدة ميلي ثانية لإكمالها. نظرًا لاستدعاءات قاعدة البيانات المتزامنة ، يتم حظر مؤشر الترابط ولا يتوفر للطلبات الأخرى.

نحن نفكر في التبديل إلى Entity Framework ، فقط لهذه الميزة. من المؤسف أن Microsoft لم تقم بتطبيق الدعم المتزامن في Linq-to-SQL (أو من مصدر مفتوح ، لذلك يمكن للمجتمع القيام بذلك).


أعتقد أن الإجابة السريعة والقذرة هي

  • LINQ إلى SQL هي طريقة سريعة وسهلة للقيام بذلك. هذا يعني أنك سوف تحصل على أسرع ، وتقديم أسرع إذا كنت تعمل على شيء أصغر.
  • إطار الكيان هو طريقة شاملة وغير محظورة للقيام بذلك. وهذا يعني أنك ستستغرق وقتًا أطول في التقدم ، وتتطور بشكل أبطأ ، وتزيد من المرونة إذا كنت تعمل على شيء أكبر.

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

أتساءل ما الأمر مع nybernate ، أو OpenAccess ...


هناك عدد من الاختلافات الواضحة الموضحة في هذه المقالة @ lars المنشورة ، لكن الإجابة المختصرة هي:

  • يقترن L2S بإحكام - خاصية الكائن إلى حقل معين من قاعدة البيانات أو بشكل صحيح تعيين كائن إلى مخطط قاعدة بيانات محدد
  • سوف تعمل L2S فقط مع مزود خدمة (بقدر ما أعرف)
  • يسمح EF بتعيين فئة واحدة إلى جداول متعددة
  • سوف تتعامل EF مع علاقات MM
  • سيكون لدى EF القدرة على استهداف أي موفر بيانات ADO.NET

كان الافتراض الأصلي L2S هو لـ Rapid Development و EF لمزيد من تطبيقات "enterprisey" n-tier ، إلا أن بيع L2S قصير بعض الشيء.


لقد وجدت أنني لا يمكن استخدام قواعد بيانات متعددة داخل نفس نموذج قاعدة البيانات عند استخدام EF. ولكن في linq2sql يمكنني فقط عن طريق بادئة أسماء المخطط مع أسماء قواعد البيانات.

كان هذا أحد الأسباب التي بدأت في الأصل العمل مع linq2sql. لا أعلم ما إذا كانت EF قد سمحت بعد هذه الوظيفة ، لكني أتذكر أنني قررت أنها لا تسمح بذلك.


أعتقد أنه إذا كنت بحاجة إلى تطوير شيء سريع دون أي أشياء غريبة في الوسط ، وكنت بحاجة إلى منشأة لديها كيانات تمثل الجداول الخاصة بك:

Linq2Sql يمكن أن تكون متحالفة جيدة ، وذلك باستخدامه مع LinQ يطلق العنان توقيت النامية العظيم.


لقد وجدت إجابة جيدة جدًا here تشرح متى تستخدم ما بعبارة بسيطة:

تتمثل القاعدة الأساسية الأساسية لإطار العمل الذي يتم استخدامه في كيفية التخطيط لتحرير بياناتك في طبقة العرض التقديمي.

  • Linq-To-Sql - استخدم هذا الإطار إذا كنت تخطط لتحرير علاقة رأس برأس لبياناتك في طبقة العرض التقديمي. بمعنى أنك لا تخطط لدمج البيانات من أكثر من جدول في أي عرض أو صفحة واحدة.

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

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

ربما تكون هناك أسباب أكثر دقة لاختيار EF عبر L2S ، ولكن ربما يكون هذا هو أسهل ما يمكن فهمه. لا تملك L2S القدرة على دمج البيانات لعرض العرض التقديمي.


إذا كانت قاعدة البيانات الخاصة بك بسيطة وبسيطة ، فستقوم LINQ بـ SQL بذلك. إذا كنت تحتاج إلى كيانات منطقية / مستخلصة أعلى جداولك ، فانتقل إلى Entity Framework.


LINQ إلى SQL

  1. مصدر بيانات متجانس: SQL Server
  2. موصى به للمشاريع الصغيرة فقط حيث تم تصميم بنية البيانات بشكل جيد
  3. يمكن تغيير التعيين دون recompilling مع SqlMetal.exe
  4. .dbml (لغة ترميز قواعد البيانات)
  5. تعيين رأس برأس بين الجداول والفئات
  6. يدعم وراثة TPH
  7. لا يدعم أنواع معقدة
  8. نهج التخزين الأول
  9. عرض قاعدة البيانات مركزية لقاعدة البيانات
  10. تم إنشاؤها بواسطة فريق C #
  11. دعم ولكن لا مزيد من التحسينات المقصود

إطار كيان

  1. Heterogeneus datasource: دعم العديد من مزودي البيانات
  2. موصى به لجميع المشاريع الجديدة باستثناء:
    • صغيرة (LINQ إلى SQL)
    • عندما يكون مصدر البيانات ملف مسطح (ADO.NET)
  3. يمكن تغيير التعيين دون إعادة الضبط عند تعيين نموذج وملفات التعيينات عملية القطع الأولية للبيانات إلى نسخ إلى دليل الإخراج
  4. .edmx (نموذج بيانات الكيان) الذي يحتوي على:
    • SSDL (لغة تعريف مخطط التخزين)
    • CSDL (لغة تعريف المفهوم المخطط)
    • MSL (لغة مواصفات الخرائط)
  5. واحد إلى واحد أو واحد إلى أطراف العديد من التعيينات بين الجداول والفئات
  6. يدعم الإرث:
    • TPH (جدول في التسلسل الهرمي)
    • TPT (جدول لكل نوع)
    • TPC (الجدول حسب فئة الخرسانة)
  7. يدعم أنواع معقدة
  8. الطريقة الأولى ، النموذج الأول ، نُهج التخزين أولاً
  9. عرض مركزية التطبيق من قاعدة البيانات
  10. تم إنشاؤها بواسطة فريق SQL Server
  11. مستقبل واجهات برمجة تطبيقات بيانات Microsoft

أنظر أيضا:


يدعم LINQ إلى SQL فقط 1 إلى 1 تعيين جداول قاعدة البيانات وطرق العرض sprocs والوظائف المتوفرة في Microsoft SQL Server. إنها واجهة برمجة تطبيقات رائعة لاستخدامها في إنشاء الوصول السريع إلى البيانات إلى قواعد بيانات SQL Server مصممة جيدًا نسبيًا. تم إصدار LINQ2SQL لأول مرة باستخدام C # 3.0 و .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) هو واجهة تعامل ORM (Object Relational Mapper) API التي تسمح بتعريف واسع لنماذج مجال الكائن وعلاقاتها بموفري بيانات ADO.Net مختلفين. على هذا النحو ، يمكنك مزج ومطابقة عدد من بائعي قواعد البيانات المختلفة أو خوادم التطبيقات أو البروتوكولات لتصميم مجموعة مجمعة من الكائنات التي تم إنشاؤها من مجموعة متنوعة من الجداول والمصادر والخدمات وما إلى ذلك. تم إصدار ADO.Net Framework مع .Net Framework 3.5 SP1.

هذه مقالة تمهيدية جيدة على MSDN: تقديم LINQ إلى البيانات العلائقية



وفقا لدانيال سيمونز:

إنشاء مثيل ObjectContext جديد في عبارة استخدام لكل أسلوب خدمة بحيث يتم التخلص منه قبل إرجاع الأسلوب. تعد هذه الخطوة ضرورية لقابلية تطوير خدمتك. تأكد من أن اتصالات قاعدة البيانات لا تبقى مفتوحة عبر مكالمات الخدمة وأن الحالة المؤقتة المستخدمة بواسطة عملية معينة هي البيانات المهملة التي يتم جمعها عند انتهاء هذه العملية. يقوم نظام Entity Framework تلقائيًا بتخزين البيانات الوصفية وغيرها من المعلومات التي يحتاج إليها في مجال التطبيق ، كما يقوم ADO.NET بتخزين اتصالات قاعدة البيانات ، لذا فإن إعادة إنشاء السياق في كل مرة عملية سريعة.

هذا من مقالته الشاملة هنا:

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

أعتقد أن هذه النصيحة تمتد إلى طلبات HTTP ، لذا ستكون صالحة لـ ASP.NET. قد يكون تطبيقًا حكوميًا ودهونًا مثل تطبيق WPF هو الحالة الوحيدة للسياق "المشترك".





.net entity-framework linq-to-sql