موقع معضلة الواجهات

Question

بالنظر إلى مشروع التعليمات البرمجية الذي من المفترض أن يلتزم بمبدأ SoC من خلال تنفيذ طبقات مقترنة بشكل غير محكم، مع وجود حاوية IoC، وما إلى ذلك، على سبيل المثال، حل ASP.NET MVC بسيط مقسم إلى التجميعات التالية:

• طلب التجمع + مساحة الاسم
• نموذج التجميع + مساحة الاسم (يحتوي على مستودع ملموس للوصول إلى بيانات قاعدة البيانات)

وحيث يوجد مستودع ملموس في نموذج يجب أن ينفذ التجميع واجهة مشتركة IMyBusinessRepository, ، في أي تجميع ستضع هذه الواجهة؟

1) إذا قمت بوضع هذه الواجهة في ملف نموذج التجميع، من المحتمل أنه سيكون من المستحيل استبدال هذا التجميع بتجميع آخر (على الأقل إذا كان يحتوي على مسافة اسم مختلفة) دون تعديل كود التجميع طلب حَشد.وأيضا بديل IMyBusinessRepository يجب أن يشير التنفيذ الموجود في مجموعة مختلفة إلى النسخة الأصلية (Argh!)

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

3) أم هل يمكنك إنشاء تجميع مشترك منفصل لتلك الواجهة فقط، وفي هذا الصدد، لكل واجهة مشتركة أو مجموعة من الواجهات؟(أرغ؟)

كي تختصر، X يجب أن يكون التجميع قابلاً للاستبدال بسهولة في التطبيق أ (فقط عن طريق تغيير مرجع)، وقابلة لإعادة الاستخدام في التطبيقات ب, ج, د.

Answer 1

الخيار 3.

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

هل يمكنك إنشاء تجميع مشترك منفصل لهذه الواجهة فقط، وفي هذا الصدد، لكل واجهة مشتركة أو مجموعة من الواجهات؟(أرغ؟)

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

Answer 2

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

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

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

Answer 3

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

Answer 4

SoC هو مفهوم منطقي تحاول ترجمته إلى مفهوم مادي.

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

أنا لا أفهم القلق أيضا.ما يمنعك من ذلك Concrete1 : IRepository و Concrete2 : IRepository في جمعية النماذج؟

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