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

Question

Я новичок в инъекции зависимости. Я никогда не использовал и никогда не понимал, что это такое, но после моей последней атаки на эту тему я обнаружил, что это способ отсоединения объекта и его зависимостей, если они не несут ответственности за создание конкретных версий его зависимости, так как теперь контейнер сделает это за нас и доставит готовый объект в наши руки.

Теперь дело в том; «Когда я должен использовать это?», ВСЕГДА ??? На самом деле, поскольку я новичок и никогда не видел проекта, использующего этот шаблон, я не могу понять, как я должен применять его к моим доменным объектам !!! Мне кажется, что я никогда больше не буду создавать экземпляры своих объектов, и контейнер всегда будет делать это для меня, но тогда возникают некоторые сомнения ...

1) Как насчет объектов, часть которых зависит от пользовательского интерфейса, например;

public class User(String name, IValidator validator)

Скажите, что я получаю имя пользователя из пользовательского интерфейса, так как же сборщик узнает его и все еще доставит мне этот объект?

2) Есть другая ситуация, с которой я сталкиваюсь; если зависимость теперь является объектом, который уже создан, скажем ... объект SINGLETON, например. Я видел настройки, относящиеся к области действия внедренного beign-зависимости (я говорю о Spring.NET, например, http-область запроса) ... НО , запрос и другие связанные с сетью вещи находятся в моей презентации слой, так как я мог связать и мой уровень представления и мой уровень домена, не нарушая никакого правила проектирования (поскольку мой домен должен полностью не знать, где он используется, не иметь зависимости уровня и т.д.)

Я очень хочу услышать от вас всех. Большое спасибо.

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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