Как организовать составные приложения масштаба предприятия (CAG)

Question

Все примеры QuickStarts и RI в документации CAG хороши, но мне не хватает примеров корпоративного масштаба.

Допустим, у нас есть более 40 модулей, каждый из которых содержит Proxy, Facade, PresentationModel, Model и Views. Каждый модуль также выполняет вызовы к специфической для модуля службе WCF, которая должна быть размещена в IIS или на автономном консольном хосте. Наш подход состоял в том, чтобы включить UI-модуль, сервисный модуль и связанные тесты в одно решение, чтобы их можно было разрабатывать и тестировать отдельно от других модулей.

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

Answer 1

В результате мы получили довольно простое решение, в которое мы включили хостинг-проект в качестве «запускающего» проекта. Проект настроен так, чтобы не создавать и иметь зависимости модуля.

Все служебные библиотеки DLL выводятся в общую папку, в которую их динамически загружает хост-проект, ищут атрибут ServiceContract и запускают хост.

Answer 2

Вы, безусловно, можете разместить каждый модуль в качестве приложения или экземпляра виртуального каталога для точек обслуживания, но, думаю, можно сказать, что вы допускаете, что "удобство" разработки решений для разделения определяет производственную архитектуру для ваших служб? Обычно мы работаем с этим на основе слоев, а не разделов модулей - другими словами, у вас будет проект с доменами / моделями и один с сервисами, тогда каждый «модуль» может ссылаться на общий пул сервисов. Я полагаю, это зависит от того, насколько взаимосвязаны модули, насколько велика перекрестная связь и т. Д.

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