Используя StructureMap, одна из этих проектных организаций лучше другой?

Question

Я начинаю работать со StructureMap над проектом приложения Windows. Работая над изучением основ, я нашел 2 способа организовать свое решение, которое решает ту же задачу, и мне интересно, кто-нибудь может прокомментировать, если один из этих двух вариантов кажется лучшим вариантом и почему.

Цель здесь состояла в том, чтобы использовать IOC, чтобы я мог использовать 2 службы без зависимости от них. Поэтому я создал интерфейсы в своем бизнес-уровне, а затем внедрил эти интерфейсы в своем проекте инфраструктуры и обернул действительные службы в тот момент.

В своей первой попытке я создал проект DependencyResolver, в котором есть код для инициализации структуры структуры с использованием свободного интерфейса (когда кто-то хочет IServiceA, предоставьте ему экземпляр ServiceX). Поскольку инициализация DependencyResolver должна была начаться из моего приложения, у меня есть ссылка из приложения на DependencyResolver, например:

Итак, я обнаружил, что могу удалить свою ссылку на DependencyResolver и использовать сканер StructureMap и соглашения об именах, чтобы получить эту ссылку во время выполнения, поэтому моя установка выглядит следующим образом:

Итак, я пошел дальше по соглашениям об именах, к услугам, которые я использовал, и смог полностью отказаться от DependencyResolver. На данный момент, я полностью полагаюсь на сканер структурных карт и соглашения об именах для правильной настройки:

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

Вариант 2 устраняет необходимость ссылки из приложения на DependencyResolver и опирается на соглашения об именах для доступа к классам в этом проекте, и у меня все еще есть высокий уровень контроля над всеми остальными настройками (но теперь я взял зависимость от структуры карты непосредственно из моего приложения).

Вариант 3 кажется самым простым (просто назовите все определенным образом и отсканируйте свои сборки), но он также кажется более подверженным ошибкам и хрупким. Особенно, если я хочу сделать что-то более сложное, чем IServiceAbc => ServiceAbc.

Итак, может ли кто-нибудь, у кого гораздо больше опыта в этом деле, дать мне какой-нибудь совет?
Должен ли я избегать косвенных ссылок из моего приложения на мои сервисы, и если да, то каковы реальные преимущества этого? Прав ли я, что пытаться делать все с соглашениями об именах целесообразно только для простых проектов?
Есть ли стандартный шаблон для того, что я пытаюсь сделать здесь?

Извините за длинный пост ..

Answer 1

Инкапсулируйте все использование StructureMap в Composition Root и используйте Constructor Injection в остальной части вашего кода.

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

Answer 2

Я использовал лучший дизайн в проектах, и он работает очень хорошо.

Преобразователи зависимостей - это более или менее фабрики, возвращающие экземпляры интерфейса, не является ли структурная карта лишь одним из способов реализации этого? В этом случае я бы сделал запрос для любого элемента через средство разрешения зависимостей в одном центральном месте. Затем также можно удалить карту структуры и добавить еще один локатор служб (единство, замок Виндзор и т. Д.), Не изменяя ничего в своем приложении.

Зависимости не должны разрешаться из двух мест, как видно в вашем втором варианте, и не только через проект пользовательского интерфейса в третьем варианте (что произойдет, если вы поменяете свой проект пользовательского интерфейса и вставите в него другой?).