IoC (StructureMap) Лучшая практика

Question

По моему (вероятно, скудному) пониманию, выполнение этого в середине метода в вашем контроллере / докладчике считается плохой практикой, поскольку оно создает зависимость между StructureMap и вашим докладчиком:

void Override() {
    ICommentForOverrideGetter comm = StructureMap.ObjectFactory.GetInstance<ICommentForOverrideGetter>();

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

Answer 1

Если вы настаиваете на размещении службы в вашем методе, вы должны как минимум внедрить контейнер в свой контроллер, чтобы исключить статический вызов метода.Добавьте параметр конструктора типа StructureMap.IContainer и сохраните его в переменной поля.StructureMap вставит правильный контейнер.Затем вы можете вызвать GetInstance () для этого контейнера вместо ObjectFactory.

Answer 2

Говорят, что в компьютерной науке нет проблемы, которая не может быть решена еще одним уровнем косвенности:

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

Edit:

«У меня нет проблем с игнорированием лучших практик, когда я считаю, что соотношение сложность / выгода слишком велико»: я тоже так не делаю, но, как я сказал в комментариях, мне не нравятся жесткие зависимости от контейнеров IoC в коде, который я хочу для модульного тестирования и ведущие такие случаи.

В зависимости от того, что делает ваш ICommentForOverrideGetter, вы также можете использовать простой CommentForOverrideGetter.CreateNew (), но, поскольку вам требуется свежий экземпляр для вызова, я подозреваю, по крайней мере, какую-то логику, связанную с созданием? Или это «служба» с состоянием?