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

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

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

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


visual-studio-2010 .net c# prism cag
person David    schedule 03.06.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

person Jeremy Likness    schedule 03.06.2010
comment
Наша цель № 1 при создании модулей — сократить время разработки и непрерывного тестирования, поэтому мы хотим иметь вертикали, которые можно разрабатывать и тестировать независимо. Сегодня, во время разработки, мы не используем IIS для хостинга, но, возможно, это путь вперед. Тогда решение на самом деле не отвечает за запуск нового хоста консоли каждый раз, когда я хочу собрать и запустить решение, и просто развертывает файлы в папку, на которую указывает IIS. - person David; 09.06.2010

arrow_upward
1
arrow_downward

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

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

person David    schedule 15.06.2010