Дизайн - решение адской зависимости?

Question

Мы используем архитектуру MVC с моделью, состоящей из BLL и DAL.

Таким образом, мы разрабатываем «модули» для нашей системы, а конкретный, который я реализую, использует множество одинаковых зависимостей. В частности, один класс имеет 20 зависимостей. В настоящее время конструктор по умолчанию создает конкретную реализацию по умолчанию, и у нас также есть второй конструктор [который используется первым], который позволяет вводить свои собственные зависимости (т. Е. Тестирование.)

20 аргументов конструктора кажутся довольно неприятным запахом кода. Другая досадная вещь заключается в том, что часто, когда я начинаю добавлять общие функции, мне нужно добавлять код конструктора и поля в каждом классе, часто повторяя один и тот же тип кода снова и снова.

Контейнер IoC кажется естественным решением, но проблема в том, как далеко я зайду? Нужно ли включать зависимости DAL и зависимости BLL? А как насчет "вспомогательных" или "служебных" зависимостей? Кажется, что в определенный момент я просто воссоздаю структуру «пространства имен» с возможностью ссылаться на мои классы как статические классы, и в этот момент я подвергаю сомнению то, что на самом деле получаю.

У меня проблемы с обдумыванием этого. У кого-нибудь есть элегантное решение или совет?

Answer 1

Если вы пойдете по маршруту IoC (который я рекомендую), я включу все ваши зависимости в контейнер.

Преимущество заключается в том, что вам никогда не придется беспокоиться о создании этих зависимостей, даже если их тонна многоуровневая.

например, ClassA принимает в своем конструкторе 4 других класса, каждый из которых принимает два других в своем, и каждый из них принимает как минимум ссылку DAL.

В этом случае вам просто нужно сослаться на IoC в вашем слое высшего уровня («корень композиции»), который может быть вашим пользовательским интерфейсом, и сказать «дай мне экземпляр объекта A» затем IoC автоматически создаст экземпляры 20 других экземпляров для различных зависимостей, необходимых для построения графа объектов.

Вашим классам больше не нужно беспокоиться о том, как создавать свои зависимости, если им нужно что-то, они просто вставляют это в конструктор, и IoC гарантирует, что оно его получит.

Я бы также прокомментировал, что 20 зависимостей в одном классе - это определенный запах кода, даже если вы используете IoC . Обычно это указывает на то, что класс делает слишком много вещей и нарушает Принцип единой ответственности .