طرق مختلفة لحقن التبعيات في وحدات تحكم ASP.NET MVC؟

Question

في معظم العينات التي رأيتها على الويب، يتم إجراء DI في وحدات تحكم MVC على هذا النحو

public ProductController(IProductRepository Rep)
{
    this._rep = Rep;
}

يتم استخدام ControllerFactory مخصص ويستخدم إطار عمل DI المفضل ويتم حقن المستودع.

لماذا يعتبر ما سبق أفضل من

public ProuctController()
{
    this._rep = ObjectFactory.GetInstance<IProductRepository>();
}

سيحصل هذا على نفس النتائج ولكنه لا يتطلب مصنعًا مخصصًا لوحدات التحكم.

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

Answer 1

وحقن منشئ (النهج الأول) هو أفضل من نمط خدمة تحديد المواقع (النهج الثاني) لعدة أسباب.

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

ما هو أكثر من ذلك، لقد حصلت على صدى <لأ href = "https://stackoverflow.com/questions/1044403/different-ways-to-inject-dependencies-in-asp-net-mvc-controllers/1044512 # 1044512 "> OdeToCode . أعتقد

IProductRepository repository = Mockery.NewMock<IProductRepository>();
IProductController controller = new ProductController(repository);

وهو أكثر وضوحا من

ObjectFactory.SetFactory(IProductRepository, new MockRepositoryFactory())
IProductController controller = new ProductController();

وخصوصا إذا تم تكوين ObjectFactory في طريقة SetUp لاعبا اساسيا الاختبار.

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

و(مارتن فاولر يقدم تحليل أكثر دقة بكثير في "عكس من حاويات تحكم وحقن نمط التبعية" ، وخاصة قسم "خدمة محدد مقابل التبعية حقن").

Answer 2

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

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

Answer 3

عند استخدام الطريقة الثانية، فإن العيوب هي:

• هناك حاجة إلى طرق إعداد/سياق اختبار ضخمة وغير قابلة للقراءة
• الحاوية مقترنة بوحدة التحكم
• سوف تحتاج إلى كتابة المزيد من التعليمات البرمجية

لماذا تريد استخدام حاوية ioc على أي حال عندما لا تريد حقن التبعية؟