N-уровневые приложения StructureMap

Question

Я пытаюсь внедрить StructureMap в мое приложение ASP.Net MVC 3. Моя архитектура придерживается многоуровневого подхода, когда мой уровень пользовательского интерфейса взаимодействует с уровнем моих услуг, который, в свою очередь, соответствует уровню моего бизнеса, который, в свою очередь, связан с уровнем хранилища. У меня есть контракты данных, которые представляют данные, проходящие через все уровни.

Мой уровень пользовательского интерфейса должен знать только об уровне служб. Мой пользовательский интерфейс не должен знать о бизнесе или заботиться о нем, не говоря уже о хранилище или уровнях данных. Каждый уровень представляет собой свою собственную сборку, и я использую внедрение зависимостей конструктора для внедрения необходимых экземпляров (т.е. я внедряю бизнес-объект в свой конструктор службы и внедряю объект хранилища в бизнес-конструктор).

Итак, если мои уровни находятся в отдельных сборках, а сборка пользовательского интерфейса, в которой находится Карта структуры, не знает о более низких уровнях, то как мне настроить карту структуры? Я не хочу создавать ссылки в своем уровне пользовательского интерфейса на все «более низкие» уровни, которые находятся за уровнем служб. Если я сделаю это, то это потенциально откроет дверь для интерфейса, чтобы напрямую общаться с базой данных, что плохо.

Пожалуйста, помогите.

Спасибо

Tom

Answer 1

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

Это не означает, что пользовательский интерфейс должен ссылаться на них (хотя это, вероятно, самое простое решение)

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

Это будет означать, что ваш пользовательский интерфейс должен знать только об интерфейсах вашего уровня обслуживания.

Но чтобы ваше приложение могло использовать все различные части вместе, оно должно знать, какую реализацию сервиса использовать, и должно знать, какую реализацию любых зависимостей эта реализация должна использовать и т. Д. весь путь вниз по линии. Все это должно быть сделано в одном месте (я думаю, что global.ashx в приложении ASP MVC), и это единственное место, где должны существовать любые ссылки на контейнер или другие классы реализации.

Вы приложение - это комбинация всех ваших уровней вместе. Это не только ваш пользовательский интерфейс.

Если вы вообще не хотите ссылаться на эти сборки, то, возможно, вы можете сконфигурировать структурную карту через xml, который, вероятно, будет затем динамически загружать сборки. Я не уверен в этом, но это должно работать, я думаю. Конфигурация Xml более громоздка.

Пока ваш интерфейс службы внедрен в ваши контроллеры пользовательского интерфейса, вы должны быть в безопасности. Для того, чтобы кто-то использовал новую зависимость от одного из упомянутых dll, таких как слой db, ему пришлось бы ввести этот интерфейс в контроллер и связать его с картой структуры, которую должно быть легко обнаружить.

Answer 2

Там было сделано это.Взял идею прямо, как Вы, думая, что избегание ссылок на сборки решит все проблемы.Мне даже удалось сделать то, что Ты пытаешься сделать с помощью пост-сборки xcopy'ing build dll`s.В действительности - это только сделало его более запутанным, чем это должно быть.

Дело в том, что сами ссылки не являются корнем зла. Это нормально ссылаться на все из самой верхней сборки (UI).Плохой код - это то, что вызывает проблемы.

Answer 3

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

Вы должны ссылаться на все нижние уровни в конечном приложении ASP.NET, в котором сконфигурирован контейнер DI. Все сборки должны быть в папке bin при развертывании, иначе ваше приложение не будет работать.

Уровень пользовательского интерфейса (приложение ASP.NET) напрямую не взаимодействует с базой данных. Если вы должным образом абстрагировали свои сервисы, то они обращаются к абстракции сервисов, которая в терминах взаимодействует с абстракцией репозитория, которая в зависимости от того, как вы настроили свой DI, взаимодействует с хранилищем данных.