N -Layered Architecture - BLL ، DAL والواجهات. ما هي أفضل الممارسات؟

Question

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

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

سؤالي هو ما هي أفضل طريقة لإنشاء الكائن على الجانب الآخر؟ على سبيل المثال ، إذا كان لدي كائن شخص في BLL قام بتطبيق Iperson ، و persondataobject أو أي شيء آخر في DLL الذي ينفذ أيضًا Iperson ، فأنا أقضي على طريقة في DAL التي تأخذ معلمة من Iperson ، ثم في dal i ' D يجب أن تعيد بناء persondataobject للاستمرار. هل هذه أفضل طريقة؟

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

Answer 1

بشكل عام ، سوف تستهلك الكائنات الموجودة في BLL الواجهات - لا تنفذها:

على سبيل المثال ، إذا كان لدي كائن شخص في BLL قام بتطبيق Iperson ، و persondataobject أو أي شيء في DLL الذي ينفذ أيضًا Iperson

أخذ "شخص" كمثال: فكر في عمليات البيانات المختلفة المرتبطة بشخص ما (الحصول على جميع البيانات لشخص واحد ، ومجموعة من البيانات الضحلة للعديد من الأشخاص ، وعمليات crud ، والبحث ، وما إلى ذلك) - ثم تصميم واجهات على طول المجموعات المنطقية (انظر واجهة مبدأ segeragtion).

قد تمثل الواجهات عمليات من منظور BL المتمركز - أو "الخدمة" القائمة.

على أي حال ، للإجابة على سؤالك المحدد ...

أقوم بتحديد ما يعادل DTO في مجموعة مشتركة ، وواجهة البيانات في واحدة منفصلة أيضًا - لذلك لدي 4 مجموعات: BL ، تعريف INTEFACE للوصول إلى البيانات ، تنفيذ الواجهة والشائع ؛ جميع التجميعات تشير إلى واحد مشترك.

أنا أعمل في C#.NET ، أقوم بتحديد DTOs كهياكل (ولكن يمكنك استخدام الفصول) ؛ وجميع خصائص هذه القراءة - تقوم بتغذية البيانات فيها في المنشئ - وبهذه الطريقة تكون DTO's "غلاف" من المعلومات.

Answer 2

أثناء اتباع بنية N-Tier ، من الشائع جدًا مشاركة كائنات البيانات بين BL و DAL. في بعض الأحيان ، يمكن استخدام نفس كائن البيانات في طبقة واجهة المستخدم أيضًا.

عادةً ما يكون لدي نموذج بيانات (أو كائنات بيانات أو نموذج مجال ، مهما كانت تسميته) يضم جميع كائنات النموذج كواجهات. أخذ مثال شعبك ، سأقوم بإنشاء واجهة ipeople في مجموعة النماذج. ستعيد DAL مثيل Ipeople إلى BL. سوف تستهلك BL هذا المثيل وإذا لزم الأمر تمريره إلى طبقة واجهة المستخدم بعد تطبيق منطق العمل.

Answer 3

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