Вопрос по DI и как решить некоторые проблемы

В общем, как только вы переходите на IoC, вы, как правило, хотите зарегистрировать ВСЕ с помощью IoC и заставить контейнер выплевывать полностью гидратированные объекты. Тем не менее, вы поднимаете некоторые важные моменты.

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

Что касается пункта 1, некоторые платформы IoC плохо справляются с внешними параметрами. Однако обычно вы можете зарегистрировать делегата в качестве фабричного метода. Этот делегат может принадлежать объекту, например контроллеру, который получает внешнюю информацию от пользовательского интерфейса. Прекрасным примером являются логины: создайте объект, скажем, LoginController, и зарегистрируйте его в IoC как свой ILoginController. Вы будете ссылаться на этот контроллер на своей странице входа, он будет внедрен при создании экземпляра страницы входа, и страница входа передаст ему введенные учетные данные. Затем контроллер выполнит аутентификацию и будет иметь метод GetAuthenticatedUser(), который создает объект пользователя. Вы можете зарегистрировать этот метод в IoC как фабрику для пользователей, и всякий раз, когда потребуется пользователь, делегат фабрики будет либо оцениваться, либо полностью передаваться зависимому методу, который будет вызывать его, когда ему действительно нужен пользователь.

В пункте 2 настройка одного экземпляра объекта является сильной стороной шаблона IoC. Вместо того, чтобы создавать настоящий синглтон с частным конструктором экземпляра, статическим экземпляром и статическим конструктором для создания экземпляра, вы просто регистрируете класс с помощью IoC и говорите ему создавать его экземпляр только один раз и использовать этот экземпляр для всех запросов. Сила — это гибкость; если позже вы захотите, чтобы их было более одного экземпляра, вы просто измените регистрацию. В любом случае вы не нарушите никаких правил шаблонов проектирования; представление всегда будет иметь введенный контроллер, независимо от того, является ли этот контроллер одинаковым для всех страниц или новым экземпляром для каждого запроса.

1) этот конструктор, вероятно, не подходит для использования, возможно, вы вводите валидатор не в то место/способ.

2) Ни представление, ни модель, ни контроллер не должны знать о наличии IoC, он должен лежать в фоновой архитектуре (где фактически создаются экземпляры компонентов MVC)

Вы должны использовать IoC, когда чувствуете, что архитектура может стать сложной и должна поддерживаться многими людьми. Если вы пишете корпоративное приложение или пользовательский интерфейс, который вы планируете расширить с помощью плагинов, он вам, вероятно, понадобится, если вы пишете утилиту командной строки, вероятно, нет.

Вы должны использовать внедрение зависимостей всякий раз, когда вам нужны какие-либо из следующих преимуществ:

• Возможность легкой замены модулей
• Возможность повторного использования модулей между частями приложения или разными приложениями
• Когда вы хотите заниматься параллельной разработкой, чтобы компоненты системы можно было разрабатывать изолированно и параллельно, потому что они зависят от абстракций.
• Когда вы хотите упростить обслуживание системы из-за слабой связанности
• Когда вам нужна тестируемость (специализация по замене модулей). Это одна из основных причин использования DI.

Чтобы ответить на другие ваши вопросы:

1) Вы можете настроить множество контейнеров IoC, чтобы можно было указать определенные параметры конструктора, в то время как другие разрешались контейнером. Однако вам, возможно, придется подумать о рефакторинге этого фрагмента кода, так как UserFactory может быть более подходящим, который принимает зависимость от валидатора и имеет метод NewUser, который принимает имя пользователя и возвращает нового пользователя (либо создавая его экземпляр напрямую, либо разрешая из контейнер).

2) Каждое приложение, которое вы создаете, будет иметь корень композиции, в котором настроен ваш контейнер, и разрешен корневой объект. Таким образом, каждое приложение будет иметь свою собственную конфигурацию IoC, поэтому существует ожидаемая связь между типом приложения и параметрами конфигурации. Любые общие регистрации абстракций могут быть помещены в код конфигурации, который может использоваться всеми приложениями.