أفضل ممارسات طبقة البيانات

Question

أنا في منتصف "مناقشة" مع أحد زملائي حول أفضل طريقة لتنفيذ طبقة البيانات في تطبيق جديد.

إحدى وجهات النظر هي أن طبقة البيانات يجب أن تكون على دراية بكائنات الأعمال (الفئات الخاصة بنا التي تمثل كيانًا)، وتكون قادرة على العمل مع هذا الكائن محليًا.

وجهة النظر المعارضة هي أن طبقة البيانات يجب أن تكون غير محددة للكائنات، وأن تتعامل بشكل بحت مع أنواع البيانات البسيطة (السلاسل، المنطقيات، التواريخ، وما إلى ذلك)

أستطيع أن أرى أن كلا النهجين قد يكونا صالحين، ولكن وجهة نظري هي أنني أفضل الأول.بهذه الطريقة، إذا تغير وسيط تخزين البيانات، فلن تحتاج (بالضرورة) إلى تغيير طبقة الأعمال لاستيعاب طبقة البيانات الجديدة.ولذلك سيكون أمرًا تافهًا التغيير من مخزن بيانات SQL إلى مخزن نظام ملفات XML المتسلسل.

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

الآن، أعلم أن هذا أحد الأسئلة التي لديها القدرة على بدء حرب دينية، لكنني أقدر أي تعليقات من المجتمع حول كيفية التعامل مع مثل هذه الأمور.

تيا

Answer 1

يعتمد الأمر حقًا على نظرتك للعالم - اعتدت أن أكون في المعسكر المنفصل.كان DAL موجودًا فقط لتزويد BAL بالبيانات - نهاية القصة.

مع التقنيات الناشئة مثل Linq إلى SQL وEntity Framework التي أصبحت أكثر شيوعًا، أصبح الخط الفاصل بين DAL وBAL غير واضح قليلاً.في L2S، يكون DAL الخاص بك مقترنًا بشكل وثيق بكائنات الأعمال حيث أن نموذج الكائن يحتوي على تعيين 1-1 لحقل قاعدة البيانات الخاصة بك.

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

Answer 2

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

Answer 3

لدي كتاب ممتاز، والذي يغطي هذا الموضوع، هو أنماط الوصول إلى البيانات, بقلم كليفتون نوك.لقد حصلت على العديد من التفسيرات الجيدة والأفكار الجيدة حول كيفية فصل طبقة عملك عن طبقة الثبات.يجب عليك حقا أن تجربها.إنه أحد كتبي المفضلة

Answer 4

كتب جيفري باليرمو مقالًا جيدًا حول هذا الموضوع.لقد دعاه العمارة البصلية.

Answer 5

إحدى الحيل التي وجدتها مفيدة هي جعل طبقة البيانات الخاصة بي "محايدة للمجموعة".أي أنه عندما أرغب في إرجاع قائمة بالكائنات من طبقة البيانات الخاصة بي، أطلب من المتصل المرور في القائمة.لذا بدلاً من هذا:

public IList<Foo> GetFoosById(int id) { ... }

أفعل هذا:

public void GetFoosById(IList<Foo> foos, int id) { ... }

يتيح لي هذا المرور بقائمة قديمة بسيطة إذا كان هذا هو كل ما أحتاج إليه، أو تطبيق أكثر ذكاءً لـ IList<T> (مثل ObservableCollection<T>) إذا كنت أخطط للربط بها من واجهة المستخدم.تتيح لي هذه التقنية أيضًا إرجاع أشياء من الطريقة مثل ValidationResult التي تحتوي على رسالة خطأ في حالة حدوثها.

لا يزال هذا يعني أن طبقة البيانات الخاصة بي تعرف تعريفات الكائنات الخاصة بي، ولكنها تمنحني درجة إضافية من المرونة.

Answer 6

تحقق من Linq to SQL، إذا كنت أقوم بإنشاء تطبيق جديد الآن، فسأفكر في الاعتماد على طبقة بيانات تعتمد بالكامل على Linq.

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

Answer 7

في التطبيقات التي نستخدم فيها NHibernate، تصبح الإجابة "في مكان ما بينهما"، حيث تكون تعريفات تعيين XML (التي تحدد الجدول الذي ينتمي إلى أي كائن والأعمدة التي تنتمي إلى أي حقل، وما إلى ذلك) بوضوح في طبقة كائن الأعمال .

ويتم تمريرها إلى مدير جلسة البيانات العامة الذي ليس على علم بأي من كائنات الأعمال؛الشرط الوحيد هو أن كائنات الأعمال التي تم تمريرها إليها من أجل CRUD يجب أن تحتوي على ملف تعيين.

Answer 8

منشور قديم ولكنني أبحث عن معلومات مماثلة عثرت عليها هذا وهو ما يفسر ذلك بشكل جيد.