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




9 Answers

يدعم 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 إلى البيانات العلائقية

entity framework

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

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

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




هل LINQ إلى SQL Truly Dead؟ بواسطة جوناثان آلن لموقع 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 إلى الكيانات الحل الموصى به للوصول إلى البيانات من أجل LINQ إلى السيناريوهات العلائقية.




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




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

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

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

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

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

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




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

مقدمة من Microsoft:

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

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

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

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

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

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




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

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




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

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




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

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

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




ينق إلى SQL

فمن مزود أنه يدعم SQL Server فقط. إنها تقنية تعيين لتعيين جداول قاعدة بيانات SQL Server إلى كائنات .NET. هي أول محاولة لـ Microsoft في ORM - مخطط كائن Relational.

ينق إلى الكيانات

هي نفس الفكرة ، ولكن باستخدام Entity Framework في الخلفية ، مثل ORM - مرة أخرى من Microsoft ، وهي تدعم ميزة قاعدة البيانات الرئيسية المتعددة لإطار عمل الكيان ، فالمطور يمكن أن يعمل على أي قاعدة بيانات لا يحتاج إلى تعلم بناء الجملة لأداء أي عملية على قواعد بيانات مختلفة

وفقا لتجربتي الشخصية EF هو أفضل (إذا لم يكن لديك أي فكرة عن SQL) الأداء في LINQ أسرع قليلا مقارنة مع EF سبب LINQ لغة مكتوبة في لامدا.




Related