سؤال

أقوم بإعداد مشروع Windows جديد وأتساءل عن نوع تقنية DAL التي يجب استخدامها. في الأصل كنت أبحث عن شيء أبسط لعدم قضاء الكثير من الوقت في بنائه. لكنني أفهم أيضًا أنه يجب أن يكون فعالًا وقابل للتطوير على المدى الطويل.

أخطط لاستخدام عميل WPF (MVVM) وخدمة WCF على نظام 3 طبقة.

فقط لتلخيص جميع التقنيات الحالية التي أعرفها:

مجموعات البيانات

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

كونترا: الطراز القديم جدا. يعتبرها البعض كأشياء/نماذج تجارية حقيقية ولكن مجرد مرآة لجداول بيانات SQL الخاصة بك. قد يكون تمريرها بين خدمة WCF/العميل أكثر صعوبة من كائنات الأعمال التي تم إنشاؤها ذاتيًا.

مكتبة المؤسسة 4.1 - كتلة الوصول إلى البيانات

Pro: يتم وضع DAL بشكل جميل في نمط المصنع. يعتني بفتح وإغلاق الاتصال تلقائيًا. سهل الاستخدام للغاية في معظمها. وهو يدعم كلا من مجموعات البيانات و SQL SPS العادية لإنشاء كائنات عملك الخاصة. كجزء من الإطار المستمر ، يمكن أن يكون استخدامه أكثر فاعلية مع بقية مكتبة المؤسسة لمنتج نهائي فعال.

كونترا: ؟؟

LINQ إلى SQL

Pro: Auto ينشئ جداول SQL في كائنات العمل. من السهل أن يلفت. من الناحية النظرية طريقة لطيفة جدا للقيام بذلك.

كونترا: بعد أن لعبت معها عندما خرجت ، وجدت أنه قشور وأحيانًا على الفور. تعتبر بالفعل تقنية ميتة بعد إعلان Microsoft أن Entity Framework 4.0 - كجزء من .NET 4.0 - سيكون Microsoft الموصى به. لا يُتوقع سوى عدد قليل من إصلاحات الأخطاء في .NET 4.0 ولكن لا يوجد المزيد من الخطط الممتدة.

إطار الكيان 4.0

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

أنا مغري للغاية لاستخدام Enterprise Library 4.1 - كتلة الوصول إلى البيانات وإنشاء كائنات العمل الخاصة بي. الخداع الكبير هو أن الأمر سيستغرق المزيد من الوقت لإنشاء DAL. ما لم يتمكن شخص ما من إقناعي باستخدام مجموعات البيانات من خلال كتلة الوصول إلى البيانات بدلاً من ذلك.

ما هي تعليقاتك وأفكارك؟ شكرا جزيلا ، كافي

هل كانت مفيدة؟

المحلول

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

أكبر خداع لـ Entlib ، في رأيي ، هو أنك لا تزال تدور حول كائنات البيانات الخاصة بك. تأخذ مكتبة المؤسسة الكثير من رمز السباكة من تطبيق ADO.NET مستقيم "المدرسة القديمة" ، وهو أمر رائع ، لكنه لا يولد كائنات بيانات لك يمكن استخدامها خارج المربع للاستعلام عن LINQ.

نصائح أخرى

لقد استخدمنا مجموعات البيانات السائدة مع كتلة تطبيق البيانات Entlib 4.1.

نستخدم الآن إطار الكيان. لقد حققنا تحسنا هائلاً في الإنتاجية مع إطار الكيان مقارنة مع Entlib 4.1. (Progam طبقة البيانات لمدة 80 جدول في 10 ساعات بدلاً من 80)

إطار الكيان 4 لا يزال في بيتا ، ولكن إذا كان هناك وقت قبل أن يعيش مشروعك ، فسأذهب مع EF 4. ستحصل على إنتاجية ORM في نفس الوقت مرونة استخدام POCO (كائنات CLR القديمة البسيطة)

A. تحقق أيضا nhibernate.

B. DataSet - أسرع وأسهل ، لكنك رمز كثيرًا.

كل الباقي - هناك الكثير من الأشياء الجيدة في استخدام أدوات ORM ، ولكن هناك الكثير من المشاكل مع 3 مستويات معهم.

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

لذلك - يعتمد الأمر على ما هي احتياجاتك الرئيسية ، وكم الوقت الذي تريد أن تقضيه في دراسة EL/LINQ أو NHIBERNATE قبل البدء في الترميز ، B/C يوجد منحنى تعليمي مع هذه الأدوات.

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

public interface IERepository<E>
{
    DbTransaction BeginTransaction();
    void EndTransaction();
    void Add(E entity);
    void Delete(E entity);
    int Save();

    ObjectQuery<E> DoQuery(string entitySetName);
    IList<E> SelectAll(string entitySetName);
    E SelectByKey(int Key);

    bool TrySameValueExist(string fieldName, object fieldValue, string key);
    bool TryEntity(ISpecification<E> selectSpec);

    int GetCount();
    int GetCount(ISpecification<E> selectSpec);
    int AddAndSave(E entity);

}

أنا أفضل إطار الكيان. لقد أنشأت 3 مشاريع بناءً على ذلك. إنه يعمل بسرعة كبيرة ، وخاصة الاستفسارات مع الترحيل. لذلك ، بعد أن تحتاج إلى إنشاء مستودع فئة عامة مع الأساليب الظاهرية التي تنفيذ واجهة iRepository. و هذا كل شيء. الآن لديك طريقة سريعة جدًا لإنشاء DAL كتابة رمز بسيط مثل هذا:

public class MonthRepository:Repository<Month>
{

}

لديك إمكانية تجاوز جميع طرق الفئة الأساسية وإنشاء الوصول إلى DB باستخدام الإجراء المخزن حيث تحتاج. ويمكنك القيام به دون تغيير التعليمات البرمجية في أماكن أخرى. ستظل ستصبحك تعيد نفس النوع من الكيانات ولكنها ستحصل عليها بطريقة أخرى.

اقرأ المزيد على http://www.codeproject.com/kb/database/implrepositorypatternef.aspx

NHibernate has the best overall mix of feature set, maturity, and support.

NHibernate, Entity Framework, active records or linq2sql

You should consider Linq support a priority for any solution you consider and your first two options above do not support Linq.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top