كيفية تقسيم طبقة البيانات وطبقة كائن الأعمال، ما هي الواجبات المناسبة لكل منهما؟

Question

إذا كان هناك خط من تطبيقات الأعمال على هذا النحو، فهل سيكون هذا تقسيمًا مناسبًا للعمل:

الدخول الى البيانات

• يستدعي فقط الإجراءات المخزنة، وخرائط خصائص DTOs إلى جدول التجزئة الذي يتم استخدامه لملء مجموعات معلمات أمر ADO.NET.

• التجميع فقط بالإشارة إلى SqlDataClient.

• منطق مهم يتعامل مع ما يعنيه فارغًا وخاليًا وفارغًا في رمز التعيين، ولكن من الحكمة الأخرى عدم وجود تحقق من الصحة أو منطق آخر خاص بالمجال.

ما يسمى بمنطق الأعمال

• تقسيم مجموعات نتائج متعددة إلى DataTables فردية، على سبيل المثال.

  الفراغ العام ReturnNthRecordSetFromStoredProcFoo()

• المرور إلى الوصول إلى البيانات لمجموعات البيانات، على سبيل المثال.

  public void returndataset (اسم السلسلة) {return (New PersonController) .GetAnotherDataset (name) ؛}

• تعيين صف واحد من DataTable إلى صف واحد DTOس

• منطق مهم يتعامل مع ما يعنيه فارغًا وخاليًا وفارغًا في رمز التعيين.
• يحتفظ بكائن المعاملة، على الرغم من استخدامه حصريًا لالتفاف استدعاءات الإجراءات المخزنة الفردية.
• لا يحتوي على مرجع إلى SqlDataClient، لذا لا يمكنه استخدام SqlDataReaders لملء DTOs
• لا توجد إشارة إلى System.Web.UI
• قواعد التفويض، ولكن بخلاف ذلك لا يوجد منطق محدد للمجال.

واجهة المستخدم

• ربط بيانات طريقتين لـ DTOs بنماذج ASP.NET.
• التحقق من صحة خصائص عناصر التحكم - لا يوجد عمومًا التحقق من الصحة بشكل مباشر ضد DTOs
• يتم التنقل في "المجموعات" عن طريق ربط مجموعات البيانات بالشبكات.في الواقع، تتطلب محاولة القيام بأي شيء باستخدام المجموعات أن تقوم واجهة المستخدم بالتكرار عبر DataRows في DataTables ومعرفة أسماء الأعمدة المناسبة (والتي تكون بشكل عام مشابهة نوعًا ما لـ DTOs)

لذا فإن السؤال الأخير - مع هذا التطبيق، هل ينبغي لطبقة الوصول إلى البيانات أن تتولى واجبات ما يسمى بطبقة الأعمال التي سيتم دمجها؟ أليس هذا بالفعل تطبيقًا مكونًا من طبقتين (واحدة تقريبًا!) باستثناء الإزعاج الناتج عن التجميع الإضافي؟

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

Answer 1

يبدو لي أن المسؤولية بين المستويات مشوشة بعض الشيء.تبدو طبقة البيانات قياسية إلى حد ما.طبقة الأعمال ("ما يسمى") هي المكان الذي تتشوش فيه الأمور.

بعض الأفكار حول طبقة الأعمال:

• يبدو أن هناك الكثير من تمثيلات البيانات.لقد ذكرت DataTables وDataSets وكائنات نقل البيانات.سيكون النهج القياسي عبر التطبيق بأكمله أفضل.

• أساليب طبقة الأعمال بأسماء مثل ReturnNthRecordSetFromStoredProcFoo وReturnDataSet ليست ذات معنى ولا توفر مستوى مناسبًا من التجريد لخدمات الأعمال.(ربما كانت تلك مجرد أمثلة تم اختيارها بشكل سيئ وليست من التطبيق؟)

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

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

• أعتقد أن التبعيات جيدة - لا توجد إشارة إلى Web.UI أو SQLClient من طبقة الأعمال.

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

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

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

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

Answer 2

اعتمادًا على تحميل الخادم الخاص بك، يجب تحديد عدد الطبقات المادية.إن عدد الطبقات المنطقية هو في الواقع اختيار شخصي.

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

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

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

DNRtv يحتوي على عدد قليل من مقاطع الفيديو التي يعرض فيها مصمم CSLA، Rockford Lhotka، طريقة عمل نموذج التطبيق. الجزء 1 و الجزء 2.

تبلغ مدة كل عرض ساعة واحدة فقط، وربما تساعدك في تحديد ما إذا كان هذا هو الشيء المناسب لك لاستخدامه.

Answer 3

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