Entity Framework مقابل LINQ إلى SQL
https://stackoverflow.com/questions/8676
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
الآن بعد أن تم إصدار .NET v3.5 SP1 (مع VS2008 SP1)، أصبح لدينا الآن إمكانية الوصول إلى إطار عمل كيان .NET.
سؤالي هو هذا.عند محاولة الاختيار بين استخدام Entity Framework وLINQ إلى SQL باعتباره ORM، ما الفرق؟
بالطريقة التي أفهمها، يعتبر Entity Framework (عند استخدامه مع LINQ to Entities) "الأخ الأكبر" لـ LINQ to SQL؟إذا كان هذا هو الحال - ما هي المزايا التي تتمتع بها؟ما الذي يمكن أن يفعله LINQ to SQL الذي لا يستطيع فعله بمفرده؟
المحلول
يدعم LINQ to SQL فقط تعيين 1 إلى 1 لجداول قاعدة البيانات وطرق العرض والجداول والوظائف المتوفرة في Microsoft SQL Server.إنها واجهة برمجة تطبيقات رائعة لاستخدامها في إنشاء الوصول السريع إلى البيانات لقواعد بيانات SQL Server المصممة بشكل جيد نسبيًا.تم إصدار LINQ2SQL لأول مرة مع C# 3.0 و.Net Framework 3.5.
LINQ to Entities (ADO.Net Entity Framework) عبارة عن واجهة برمجة تطبيقات ORM (Object Relational Mapper) التي تسمح بتعريف واسع لنماذج مجال الكائن وعلاقاتها بالعديد من موفري بيانات ADO.Net المختلفين.على هذا النحو، يمكنك مزج ومطابقة عدد من موردي قواعد البيانات المختلفين أو خوادم التطبيقات أو البروتوكولات لتصميم مزيج مجمع من الكائنات التي تم إنشاؤها من مجموعة متنوعة من الجداول والمصادر والخدمات وما إلى ذلك.تم إصدار ADO.Net Framework مع .Net Framework 3.5 SP1.
هذه مقالة تمهيدية جيدة عن MSDN:تقديم LINQ للبيانات العلائقية
نصائح أخرى
أعتقد أن الإجابة السريعة والقذرة هي ذلك
- LINQ to SQL هي الطريقة السريعة والسهلة للقيام بذلك.هذا يعني أنك ستبدأ العمل بشكل أسرع، وستنجز بشكل أسرع إذا كنت تعمل على شيء أصغر.
- Entity Framework هو الطريقة الشاملة وغير المحظورة للقيام بذلك.هذا يعني أنك ستستغرق المزيد من الوقت مقدمًا، وستتطور بشكل أبطأ، وستتمتع بمرونة أكبر إذا كنت تعمل على شيء أكبر.
هل LINQ إلى SQL ميت حقًا؟ بقلم جوناثان ألين لموقع InfoQ.com
يصف مات وارن [LINQ إلى SQL] بأنه شيء "لم يكن من المفترض أبدًا وجوده". في الأساس ، كان من المفترض أن تكون قائمة بمساعدتهم على تطوير LINQ حتى تصبح ORM الحقيقية جاهزة.
...
تسبب حجم Entity Framework في تفويت الموعد النهائي لـ .NET 3.5/Visual Studio 2008.تم الانتهاء منه في الوقت المناسب لما يسمى للأسف ".NET 3.5 Service Pack 1"، والذي كان أشبه بإصدار رئيسي أكثر من كونه حزمة خدمة.
...
لا يحب المطورون [ADO.NET Entity Framework] بسبب التعقيد.
...
اعتبارًا من .NET 4.0، سيكون LINQ to Entities هو الحل الموصى به للوصول إلى البيانات لـ LINQ للسيناريوهات العلائقية.
هناك عدد من الاختلافات الواضحة الموضحة في تلك المقالة التي نشرها @lars، لكن الإجابة المختصرة هي:
- يقترن L2S بإحكام - خاصية الكائن في مجال معين من قاعدة البيانات أو تعيين الكائن بشكل صحيح إلى مخطط قاعدة بيانات محدد
- لن يعمل L2S إلا مع SQL Server (على حد علمي)
- يسمح EF بتعيين فئة واحدة لجداول متعددة
- ستتعامل EF مع علاقات M-M
- سيكون لدى EF القدرة على استهداف أي مزود بيانات ADO.NET
كان الفرضية الأصلية هي L2S للتطوير السريع، وEF لمزيد من تطبيقات الطبقة n "المؤسسية"، ولكن هذا يجعل بيع L2S قصيرًا بعض الشيء.
لينك إلى SQL
- مصدر بيانات متجانس:خادم قاعدة البيانات
- يوصى به للمشاريع الصغيرة فقط حيث تم تصميم بنية البيانات بشكل جيد
- يمكن تغيير التعيين دون إعادة التحويل البرمجي باستخدام SqlMetal.exe
- .dbml (لغة ترميز قاعدة البيانات)
- رسم الخرائط واحد لواحد بين الجداول والفئات
- يدعم الهيدروكربونات النفطية في الساعة ميراث
- لا يدعم الأنواع المعقدة
- نهج التخزين أولا
- عرض مركزي لقاعدة البيانات
- تم إنشاؤها بواسطة فريق C#
- مدعوم ولكن ليس المزيد من التحسينات المقصودة
إطار كيان
- مصدر بيانات غير متجانس: دعم العديد من موفري البيانات
- يوصى به لجميع المشاريع الجديدة باستثناء:
- الصغيرة (LINQ إلى SQL)
- عندما يكون مصدر البيانات ملفًا ثابتًا (ADO.NET)
- يمكن تغيير التعيين دون إعادة التحويل البرمجي عند إعداد ملفات النموذج وتعيين البيانات الوصفية لعملية القطع الأثرية للنسخ إلى دليل المخرجات
- .edmx (نموذج بيانات الكيان) الذي يحتوي على:
- SSDL (لغة تعريف مخطط التخزين)
- CSDL (لغة تعريف المخطط المفاهيمي)
- MSL (لغة مواصفات التعيين)
- تعيينات واحد إلى واحد، واحد إلى متعدد، متعدد إلى واحد بين الجداول والفئات
- يدعم الميراث:
- TPH (جدول لكل تسلسل هرمي)
- TPT (جدول لكل نوع)
- TPC (الجدول لكل فئة خرسانية)
- يدعم الأنواع المعقدة
- نهج الكود أولاً، والنموذج أولاً، والتخزين أولاً
- عرض تتمحور حول التطبيق لقاعدة البيانات
- تم إنشاؤها بواسطة فريق SQL Server
- مستقبل واجهات برمجة تطبيقات بيانات Microsoft
أنظر أيضا:
لقد كانت تجربتي مع Entity Framework أقل من ممتازة.أولاً، عليك أن ترث من فئات EF الأساسية، لذا قل وداعًا لـ POCO.يجب أن يكون تصميمك حول EF.مع LinqtoSQL يمكنني استخدام كائنات الأعمال الموجودة لدي.بالإضافة إلى ذلك، لا يوجد تحميل بطيء، عليك تنفيذ ذلك بنفسك.هناك بعض الحلول لاستخدام POCO والتحميل البطيء، لكنها موجودة IMHO لأن EF ليست جاهزة بعد.أخطط للعودة إليه بعد 4.0
لقد وجدت إجابة جيدة جدا هنا وهو ما يوضح متى تستخدم "ماذا" بكلمات بسيطة:
القاعدة الأساسية المتمثلة في إطار العمل الذي يجب استخدامه هو كيفية التخطيط لتحرير بياناتك في طبقة العرض التقديمي.
لينك إلى Sql -استخدم هذا الإطار إذا كنت تخطط لتحرير علاقة فردية لبياناتك في طبقة العرض التقديمي.وهذا يعني أنك لا تخطط للجمع بين البيانات من أكثر من جدول واحد في أي عرض أو صفحة واحدة.
إطار كيان - استخدم هذا الإطار إذا كنت تخطط لدمج البيانات من أكثر من جدول واحد في عرضك أو صفحتك.لتوضيح ذلك ، تكون المصطلحات المذكورة أعلاه محددة للبيانات التي سيتم معالجتها في عرضك أو صفحتك ، وليس فقط معروضة.هذا أمر مهم لتفهمه.
مع إطار الكيان ، يمكنك "دمج" البيانات التي تم تقديمها معًا لتقديمها إلى طبقة العرض التقديمي في نموذج قابل للتحرير ، ثم عند تقديم هذا النموذج ، ستعرف EF كيفية تحديث جميع البيانات من الجداول المختلفة.
من المحتمل أن تكون هناك أسباب أكثر دقة لاختيار EF أكثر من L2S ، ولكن من المحتمل أن يكون هذا هو الأسهل لفهمه.L2S ليس لديه القدرة على دمج البيانات لعرض العرض.
انطباعي هو أن قاعدة البيانات الخاصة بك ضخمة جدًا أو مصممة بشكل سيء للغاية إذا كان Linq2Sql لا يناسب احتياجاتك.لدي حوالي 10 مواقع ويب أكبر وأصغر تستخدم جميعها Linq2Sql.لقد بحثت في Entity Framework عدة مرات ولكن لا يمكنني العثور على سبب وجيه لاستخدامه عبر Linq2Sql.ومع ذلك، أحاول استخدام قواعد البيانات الخاصة بي كنموذج، لذلك لدي بالفعل تعيين 1 إلى 1 بين النموذج وقاعدة البيانات.
في وظيفتي الحالية لدينا قاعدة بيانات تحتوي على أكثر من 200 جدول.قاعدة بيانات قديمة تحتوي على الكثير من الحلول السيئة لذلك يمكنني رؤية فائدة Entity Framework على Linq2Sql ولكني ما زلت أفضل إعادة تصميم قاعدة البيانات نظرًا لأن قاعدة البيانات هي محرك التطبيق وإذا كانت قاعدة البيانات مصممة بشكل سيء وبطيئة فإن تطبيقي سيكون بطيئًا أيضًا.يبدو استخدام Entity Framework في قاعدة البيانات هذه بمثابة حل سريع لإخفاء النموذج السيئ، لكنه لا يمكنه أبدًا إخفاء الأداء السيئ الذي تحصل عليه من قاعدة البيانات هذه.
لقد غطت الإجابات هنا العديد من الاختلافات بين Linq2Sql وEF، ولكن هناك نقطة أساسية لم تحظ بالكثير من الاهتمام:يدعم Linq2Sql SQL Server فقط بينما لدى EF موفري أنظمة RDBMS التالية:
مقدمة من مايكروسوفت:
- برامج تشغيل ADO.NET لـ SQL Server وOBDC وOLE DB
عبر موفري الطرف الثالث:
- ماي إس كيو إل
- وحي
- DB2
- VistaDB
- سكليتي
- PostgreSQL
- إنفورميكس
- U2
- سايبيس
- سينرجيكس
- فايربيرد
- نبجسكل
على سبيل المثال لا الحصر.
وهذا يجعل من EF تجريدًا برمجيًا قويًا لمخزن البيانات الارتباطية الخاص بك، مما يعني أن المطورين لديهم نموذج برمجة متسق للعمل معه بغض النظر عن مخزن البيانات الأساسي.قد يكون هذا مفيدًا جدًا في المواقف التي تقوم فيها بتطوير منتج تريد التأكد من أنه سيعمل مع نطاق واسع من أنظمة RDBMS الشائعة.
هناك موقف آخر حيث يكون هذا التجريد مفيدًا وهو عندما تكون جزءًا من فريق تطوير يعمل مع عدد من العملاء المختلفين، أو وحدات عمل مختلفة داخل المؤسسة، وترغب في تحسين إنتاجية المطورين عن طريق تقليل عدد أنظمة إدارة قواعد البيانات (RDBMS) التي يجب أن يصبحوا عليها على دراية من أجل دعم مجموعة من التطبيقات المختلفة بالإضافة إلى أنظمة RDBMS المختلفة.
لقد وجدت أنني لا أستطيع استخدام قواعد بيانات متعددة ضمن نفس نموذج قاعدة البيانات عند استخدام EF.لكن في linq2sql يمكنني فقط إضافة بادئة لأسماء المخططات بأسماء قواعد البيانات.
كان هذا أحد الأسباب التي جعلتني أبدأ العمل مع linq2sql.لا أعرف ما إذا كانت EF قد سمحت بهذه الوظيفة حتى الآن، لكني أتذكر أنني قرأت أنه كان من المفترض عدم السماح بذلك.
إذا كانت قاعدة البيانات الخاصة بك واضحة ومباشرة، فإن LINQ إلى SQL سيفي بالغرض.إذا كنت بحاجة إلى كيانات منطقية/مجردة أعلى جداولك، فانتقل إلى Entity Framework.
ولا يدعم أي منهما حتى الآن أنواع بيانات SQL 2008 الفريدة.الفرق من وجهة نظري هو أن Entity لا يزال لديه فرصة لبناء نموذج حول نوع البيانات الجغرافية الخاصة بي في بعض الإصدارات المستقبلية، ولن يتم التخلي عن Linq to SQL أبدًا.
أتساءل ما الأمر مع nHibernate، أو OpenAccess...
أعتقد أنه إذا كنت بحاجة إلى تطوير شيء سريع مع عدم وجود أشياء غريبة في المنتصف، وتحتاج إلى تسهيلات للحصول على كيانات تمثل جداولك:
يمكن أن يكون Linq2Sql حليفًا جيدًا، حيث يؤدي استخدامه مع LinQ إلى إطلاق العنان لتوقيت تطوير رائع.
أنا أعمل لصالح عميل لديه مشروع كبير يستخدم Linq-to-SQL.عندما بدأ المشروع، كان هذا هو الاختيار الواضح، لأن Entity Framework كان يفتقر إلى بعض الميزات الرئيسية في ذلك الوقت وكان أداء Linq-to-SQL أفضل بكثير.
لقد تطورت EF الآن ويفتقر Linq-to-SQL إلى دعم غير متزامن، وهو أمر رائع بالنسبة للخدمات القابلة للتطوير بشكل كبير.لدينا أكثر من 100 طلب في الثانية أحيانًا، وعلى الرغم من أننا قمنا بتحسين قواعد البيانات لدينا، إلا أن معظم الاستعلامات لا تزال تستغرق عدة أجزاء من الثانية حتى تكتمل.بسبب استدعاءات قاعدة البيانات المتزامنة، تم حظر مؤشر الترابط وغير متاح للطلبات الأخرى.
نحن نفكر في التبديل إلى Entity Framework، فقط لهذه الميزة.من المؤسف أن Microsoft لم تقم بتنفيذ دعم غير متزامن في Linq-to-SQL (أو لم توفره مفتوح المصدر، حتى يتمكن المجتمع من القيام بذلك).
ملحق ديسمبر 2018: تتجه Microsoft نحو .NET Core ولا يدعم Linq-2-SQL على .NET Core، لذلك تحتاج إلى الانتقال إلى EF للتأكد من أنه يمكنك الترحيل إلى EF.Core في المستقبل.
هناك أيضًا بعض الخيارات الأخرى التي يجب مراعاتها، مثل LLBLGen.إنه حل ORM ناضج موجود بالفعل منذ وقت طويل وقد أثبت أنه أكثر مقاومة للمستقبل من حلول بيانات MS (ODBC، ADO، ADO.NET، Linq-2-SQL، EF، EF.core).
يبدو LINQ إلى SQL وEntity Framework متشابهين على السطح.كلاهما يوفرون استعلام LINQ مقابل قاعدة بيانات باستخدام نموذج بيانات.
تطورت LINQ إلى SQL من مشروع LINQ ، الذي خرج من الفريق الذي يعمل مع تطوير اللغة. في حين كان إطار الكيان مشروعًا لفريق قابلية برمجة البيانات وتركز على لغة الكيان SQL.ليس لدى Microsoft أي نية لإلغاء LINQ إلى SQL.
لا يزال LINQ to SQL جزءًا من ADO.NET بينما يحتوي Entity Framework على واجهة برمجة تطبيقات منفصلة.إطار عمل الكيان هو الإصدار الأعلى من LINQ إلى SQL. يستخدم إطار عمل Entity نموذج بيانات الكيان للربط بين التطبيق الخاص بك ومخزن البيانات الخاص بك.إن نموذج بيانات الكيان، أو EDM، هو الذي يوفر تعريفًا للمخطط المفاهيمي الخاص بك بالإضافة إلى معلومات مخطط قاعدة البيانات اللازمة للتفاعل مع قاعدة البيانات وأخيرًا مخطط التعيين الذي يرتبط بقاعدتين.
فيما يلي بعض المهام التي يؤديها Entity Framework (نموذج بيانات الكيان).
• يقوم تلقائيًا بإنشاء فئات من النموذج وتحديث تلك الفئات ديناميكيًا في أي وقت يتغير فيه النموذج.
• يعتني بكل اتصالات قاعدة البيانات بحيث لا يتحمل المطورون عبئًا بسبب الاضطرار إلى كتابة الكثير من التعليمات البرمجية للتفاعل مع قاعدة البيانات.
• توفير صيغة استعلام شائعة للاستعلام عن النموذج، وليس قاعدة البيانات، ثم ترجمة هذه الاستعلامات إلى استعلامات يمكن لقاعدة البيانات فهمها.
• يوفر آلية لتتبع التغييرات على كائنات النموذج حيث يتم استخدامها في التطبيقات وتعامل التحديثات إلى قاعدة البيانات.
لينك إلى SQL
إنه مزود يدعم SQL Server فقط.إنها تقنية تعيين لتعيين جداول قاعدة بيانات SQL Server إلى كائنات .NET.هي المحاولة الأولى لشركة Microsoft في ORM - مخطط الكائنات العلائقية.
Linq-to-Entities
هي نفس الفكرة، ولكن باستخدام Entity Framework في الخلفية، مثل ORM - مرة أخرى من Microsoft، فهي تدعم قاعدة بيانات متعددة والميزة الرئيسية لإطار عمل الكيان هي أن المطور يمكنه العمل على أي قاعدة بيانات ولا حاجة لتعلم بناء الجملة لتنفيذ أي عملية على قواعد بيانات مختلفة مختلفة
وفقًا لتجربتي الشخصية ، فإن EF أفضل (إذا لم يكن لديك أي فكرة عن أداء SQL) في LINQ أسرع قليلاً كما مقارنة بلغة EF LINQ المكتوبة في Lambda.
