وحدات على نفس الطبقة في الهندسة المعمارية الطبقات

Question

من الناحية النظرية في بنية الطبقات، يمكنك الحصول على وحدات متعددة على نفس الطبقة. هل يمكن لهذا الوحدات المرجعية على بعضها البعض؟ هو ممكن من الناحية الفنية، على سبيل المثال. باستخدام .NET؟

Answer 1

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

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

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

Answer 2

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

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

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

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

ضع في اعتبارك أيضا للحفاظ على الوحدات النفاثة كلما قلنا عن بعضهم البعض، كلما كان ذلك أفضل.

Answer 3

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

ومع ذلك، يجب ألا يكون هناك أي سبب لعقد المرجع المتقاطع - ليس فقط (كما قال بافيل) تعتمد الوحدات فقط على الطبقات التي تحبطها، والتي يجب أن توجد فيها التبعية أحادية الاتجاه في جميع الحالات.

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

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