NHibernate مقابل LINQ إلى SQL
https://stackoverflow.com/questions/26971
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
باعتباري شخصًا لم يستخدم أيًا من التقنيتين في مشاريع العالم الحقيقي، أتساءل عما إذا كان أي شخص يعرف كيف يكمل كل منهما الآخر ومدى تداخل وظائفهما؟
المحلول
يفرض عليك LINQ to SQL استخدام نمط الجدول لكل فئة.تتمثل فوائد استخدام هذا النمط في أنه سريع وسهل التنفيذ ولا يتطلب سوى القليل من الجهد لتشغيل المجال الخاص بك بناءً على بنية قاعدة بيانات موجودة.بالنسبة للتطبيقات البسيطة، يعد هذا مقبولًا تمامًا (وأفضل في كثير من الأحيان)، ولكن بالنسبة للتطبيقات الأكثر تعقيدًا، غالبًا ما يقترح المطورون استخدام تصميم يحركه المجال النمط بدلاً من ذلك (وهو ما يسهله NHibernate).
المشكلة في نمط الجدول لكل فئة هي أن بنية قاعدة البيانات الخاصة بك لها تأثير مباشر على تصميم المجال الخاص بك.على سبيل المثال، لنفترض أن لديك جدول العملاء الذي يحتوي على الأعمدة التالية للاحتفاظ بمعلومات العنوان الأساسي للعميل:
- عنوان الشارع
- مدينة
- ولاية
- أَزِيز
الآن، لنفترض أنك تريد إضافة أعمدة للعنوان البريدي للعميل أيضًا، بحيث يمكنك إضافة الأعمدة التالية إلى جدول العملاء:
- MailingStreetAddress
- مدينة البريد
- MailingState
- MailingZip
باستخدام LINQ إلى SQL، سيكون لكائن العميل في المجال الخاص بك الآن خصائص لكل من هذه الأعمدة الثمانية.ولكن إذا كنت تتبع نمط تصميم يعتمد على المجال، فمن المحتمل أن تكون قد قمت بإنشاء فئة عنوان وجعل فئة العميل الخاصة بك تحتفظ بخاصيتين للعنوان، واحدة للعنوان البريدي والأخرى لعنوانهم الحالي.
هذا مثال بسيط، لكنه يوضح كيف يمكن أن يؤدي نمط الجدول لكل فئة إلى مجال كريه الرائحة إلى حد ما.في النهاية، الأمر متروك لك.مرة أخرى، بالنسبة للتطبيقات البسيطة التي تحتاج فقط إلى وظائف CRUD الأساسية (الإنشاء والقراءة والتحديث والحذف)، فإن LINQ to SQL مثالي بسبب بساطته.لكني شخصيًا أحب استخدام NHibernate لأنه يسهل مجالًا أنظف.
يحرر:@lomaxx - نعم، المثال الذي استخدمته كان مبسطًا وكان من الممكن تحسينه للعمل بشكل جيد مع LINQ إلى SQL.كنت أرغب في إبقاء الأمر أساسيًا قدر الإمكان لتوصيل هذه النقطة إلى المنزل.تبقى النقطة هي أن هناك العديد من السيناريوهات حيث يكون تحديد بنية قاعدة البيانات الخاصة بك لبنية المجال الخاص بك فكرة سيئة، أو على الأقل يؤدي إلى تصميم OO دون المستوى الأمثل.
نصائح أخرى
نقطتان غابتا حتى الآن:
لا يعمل LINQ إلى SQL مع Oracle أو أي قاعدة بيانات بصرف النظر عن SQLServer. ومع ذلك، تقدم الجهات الخارجية دعمًا أفضل لشركة Oracle، على سبيل المثال. devArt's dotConnect, ديبلينك, سرعة الضوء في Mindscape و الينق.(ليس لدي أي تجربة شخصية مع هؤلاء)
Linq إلى NHibernate يتيح لك استخدام LINQ مع nhiberate ، لذلك قد يزيل سبب عدم استخدامه.
الجديد أيضا واجهة بطلاقة لNhibernate يبدو أنه يجعل تكوين خرائط Nhibernate أقل إيلامًا.(إزالة إحدى نقاط الألم في نيبرنيت)
تحديث
يعد Linq to Nhiberate أفضل في Nhiberate v3 الموجود الآن ألفا.يبدو أن Nhiberate v3 قد يتم شحنه في نهاية هذا العام.
ال إطار كيان اعتبارًا من .net 4، بدأ أيضًا يبدو كخيار حقيقي.
@كيفن:أعتقد أن المشكلة في المثال الذي تقدمه هي أنك تستخدم تصميمًا سيئًا لقاعدة البيانات.كنت أعتقد أنك ستنشئ جدول عملاء وجدول عناوين وتطبيع الجداول.إذا قمت بذلك، يمكنك بالتأكيد استخدام Linq To SQL للسيناريو الذي تقترحه.سكوت جوثري لديه سلسلة رائعة من المشاركات حول استخدام Linq To SQL والذي أود أن أقترح عليك بشدة التحقق منه.
لا أعتقد أنه يمكنك القول أن Linq وNHibernate يكملان بعضهما البعض لأن ذلك يعني أنه يمكن استخدامهما معًا، وبينما يكون هذا ممكنًا، فمن الأفضل لك اختيار أحدهما والالتزام به.
يتيح لك NHibernate تعيين جداول قاعدة البيانات الخاصة بك لكائنات المجال الخاص بك بطريقة مرنة للغاية.كما يسمح لك باستخدام HBL للاستعلام عن قاعدة البيانات.
يتيح لك Linq to SQL أيضًا تعيين كائنات المجال الخاص بك إلى قاعدة البيانات ومع ذلك فإنه يستخدم بناء جملة استعلام Linq للاستعلام عن قاعدة البيانات
والفرق الرئيسي هنا هو أن بناء جملة استعلام Linq هو تم فحصه في وقت الترجمة بواسطة المترجم للتأكد من صحة استفساراتك.
بعض الأشياء التي يجب أن تكون على دراية بها مع linq هي أنه متاح فقط في .net 3.x ومدعوم فقط في VS2008.يتوفر NHibernate في الإصدارين 2.0 و3.x بالإضافة إلى VS2005.
بعض الأشياء التي يجب أن تكون على دراية بها مع NHibernate هي أنه لا يقوم بإنشاء كائنات المجال الخاص بك، ولا يقوم بإنشاء ملفات التعيين.تحتاج إلى القيام بذلك يدويًا.يمكن لينك
افعل هذا تلقائيًا نيابةً عنك.
يمكن لـ Fluent NHibernate إنشاء ملفات التعيين الخاصة بك بناءً على اصطلاحات بسيطة.لا توجد كتابة XML ومكتوبة بقوة.
لقد عملت مؤخرًا في مشروع، حيث كنا بحاجة إلى التغيير من Linq إلى SQL إلى NHibernate لأسباب تتعلق بالأداء.تبدو طريقة L2S في تجسيد الكائنات بشكل خاص أبطأ من طريقة NHibernate كما أن إدارة التغيير بطيئة جدًا أيضًا.وقد يكون من الصعب إيقاف تشغيل إدارة التغيير لسيناريوهات محددة لا تكون هناك حاجة إليها.
إذا كنت ستستخدم كياناتك غير المتصلة بـ DataContext - في سيناريوهات WCF على سبيل المثال - فقد تواجه مشكلة كبيرة في توصيلها بـ DataContext مرة أخرى لتحديث التغييرات.لم أواجه أية مشاكل مع ذلك مع NHibernate.
الشيء الذي سأفتقده من L2S هو في الغالب إنشاء التعليمات البرمجية التي تحافظ على تحديث العلاقات على طرفي الكيانات.ولكن أعتقد أن هناك بعض الأدوات لـ NHibernate للقيام بذلك أيضًا ...
هل يمكنك توضيح ما تقصده بـ "LINQ"؟
LINQ ليست تقنية للوصول إلى البيانات، إنها مجرد ميزة لغوية تدعم الاستعلام كبنية أصلية.يمكنه الاستعلام عن أي نموذج كائن يدعم واجهات محددة (على سبيل المثال.IQueryable).
يشير العديد من الأشخاص إلى LINQ To SQL باسم LINQ، لكن هذا ليس صحيحًا على الإطلاق.لقد أصدرت Microsoft للتو LINQ To Entities مع .NET 3.5 SP1.بالإضافة إلى ذلك، يحتوي NHibernate على واجهة LINQ، لذا يمكنك استخدام LINQ وNHibernate للحصول على بياناتك.
بواسطة LINQ، أفترض أنك تعني LINQ إلى SQL لأن LINQ، في حد ذاته، لا يحتوي على "أحداث مستمرة" في قاعدة البيانات المرتبطة به.إنها مجرد لغة استعلام تحتوي على كمية كبيرة من السكر النحوي لجعلها تبدو وكأنها SQL.
في الأمثلة الأساسية، يبدو أن NHibernate وLINQ إلى SQL يحلان نفس المشكلة.بمجرد حصولك على الترخيص ستدرك قريبًا أن NHibernate لديه دعم للعديد من الميزات التي تسمح لك بإنشاء نماذج نطاق غنية حقًا.يوجد أيضًا مشروع LINQ إلى NHibernate يسمح لك باستخدام LINQ للاستعلام عن NHibernate بنفس الطريقة التي تستخدم بها LINQ إلى SQL.
أولا دعونا نفصل بين شيئين مختلفين:تهتم نمذجة قاعدة البيانات بالبيانات بينما تهتم نمذجة الكائنات بالكيانات والعلاقات.
تتمثل ميزة Linq-to-SQL في إنشاء فئات بسرعة من مخطط قاعدة البيانات بحيث يمكن استخدامها ككائنات تسجيل نشطة (راجع تعريف نمط تصميم السجل النشط).
تتمثل ميزة NHibernate في السماح بالمرونة بين نمذجة الكائنات ونمذجة قاعدة البيانات.يمكن تصميم قاعدة البيانات لتعكس بياناتك بشكل أفضل مع الأخذ في الاعتبار الأداء على سبيل المثال.في حين أن نمذجة الكائنات الخاصة بك ستعكس بشكل أفضل عناصر قاعدة العمل باستخدام نهج مثل التصميم المبني على المجال.(انظر تعليق كيفن بانغ)
مع قواعد البيانات القديمة ذات النمذجة و/أو اصطلاحات التسمية السيئة، سيعكس Linq-to-SQL هذه الهياكل والأسماء غير المرغوب فيها إلى فصولك.ومع ذلك، يمكن لـ NHibernate إخفاء هذه الفوضى باستخدام مصممي خرائط البيانات.
في المشاريع الجديدة حيث تتمتع قواعد البيانات بتسمية جيدة وتعقيد منخفض، يمكن أن يكون Linq-to-SQL خيارًا جيدًا.
ومع ذلك يمكنك استخدام NHibernate بطلاقة مع التعيينات التلقائية لهذا الغرض نفسه مع رسم الخرائط كاتفاقية.في هذه الحالة، لا تقلق بشأن أي مخططي بيانات باستخدام XML أو C# واسمح لـ NHibernate بإنشاء مخطط قاعدة البيانات من الكيانات الخاصة بك بناءً على اتفاقية يمكنك تخصيصها.
من ناحية أخرى فإن منحنى التعلم الخاص بـ Linq-to-SQL أصغر من NHibernate.
أو يمكنك استخدام مشروع Castle ActiveRecords.لقد كنت أستخدم ذلك لفترة قصيرة لتكثيف بعض التعليمات البرمجية الجديدة لمشروع قديم.يستخدم NHibernate ويعمل على نمط السجل النشط (وهو أمر مفاجئ بالنظر إلى اسمه الذي أعرفه).لم أحاول، ولكن أفترض أنه بمجرد استخدامه، إذا شعرت بالحاجة إلى اللجوء إلى دعم NHibernate مباشرة، فلن يكون القيام بذلك كثيرًا بالنسبة لجزء من مشروعك أو كله.
كما كتبت "بالنسبة لشخص لم يستخدم أيًا منهم" LINQ إلى SQL ، من السهل استخدام أي شخص حتى يمكن لأي شخص استخدامه بسهولة ، مما يساعد في معظم الوقت.لنفترض أنك ترغب في الحصول على بيانات من أكثر من جدول واحد ، ثم اكتب إجراء واسحب هذا الإجراء إلى المصمم وسيقوم بإنشاء كل شيء من أجلك ، لنفترض أن اسم الإجراء الخاص بك هو "Customer_order_lineItem" الذي يحضر السجل من كل هذه الجدول الثلاثة ثم اكتب
MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();
يمكنك أيضًا استخدام كائن السجلات في حلقة foreach، وهو أمر غير مدعوم من قبل NHibernate
