Схема с несколькими решениями для веб-портала ASP.NET? - PullRequest
3 голосов
/ 25 декабря 2010

На работе мы разработали собственный веб-портал ASP.NET (он очень похож на iGoogle).У нас есть «Приложения» (автономные, большие веб-формы) и «Модули» (аналогично гаджетам Google).

В настоящее время мы используем модель с одним решением.Прямо сейчас у нас есть:

  • 3 основных проекта
  • 60 прикладных проектов
  • 80 модульных проектов

Для сокращения копирования и вставкимежду проектами мы собираемся выделить общие функции (доступ к данным, бизнес-логика) в отдельные проекты.Я также хотел бы представить модульные тесты, которые еще больше увеличат количество проектов.

Мы уже достигли точки, когда Visual Studio задыхается от количества проектов.Обычно мы загружаем только 3 основных проекта, а затем любой проект приложения / модуля, над которым мы работаем.

Поможет ли нам другая структура решения?Количество наших проектов будет только увеличиваться.

В общем, приложение или модуль ссылаются только на 3 основных проекта.Вскоре приложения / модули могут начать ссылаться на проекты Data Access / Business Logic.Но в целом приложения и модули не делают ссылок между собой.

Итак, напомним, что является лучшим методом для структуры решений, когда существует МНОГИЕ проекты, использующие небольшое количество основных проектов?

1 Ответ

0 голосов
/ 27 декабря 2010

Мы разработали аналогичные веб-порталы ASP.NET на основе строгих модульных принципов. Налог, который мы платим, это множество проектов Visual Studio. Существует единственное мастер-решение со всеми модулями, веб-сайтами, модульными тестами и т. Д., Но с этим решением обычно невозможно работать изо дня в день на компьютерах с небольшим объемом ОЗУ (<= 4 ГБ). </p>

У нас есть общий код инфраструктуры (~ 10 проектов) и проекты бизнес-модулей. Один бизнес-модуль состоит из всех проектов, связанных с некоторыми аспектами бизнес-требований, например, Заказы, Управление клиентами, Распределение ... Бизнес-модуль обычно имеет:

  • Проект веб-приложения ASP.NET (который становится дочерней веб-страницей модуля Shell),
  • сборка модели домена (библиотека классов без зависимостей) + сборка интерфейса,
  • ИЛИ / M адаптер для доменной модели (мы используем Entity Framework и NHibernate),
  • интерфейсная сборка с презентаторами, контроллерами, моделями просмотра, ...,
  • внутренняя сборка с модульными бизнес-службами и сборкой интерфейса DTO +,
  • модульные сборки,
  • другие сборки (такие как компоненты Silverlight, MSQM DTO и т. Д.).

Мы используем SLNTools Filter (http://slntools.codeplex.com/), чтобы отфильтровать решения VS для единого бизнес-модуля из основного решения. Таким образом, у нас есть решения OrdersModule.sln, CustomersModule.sln и т. Д. Каждое такое решение имеет общие инфраструктурные проекты (~ 10 ) и проекты модулей (~ 10-15). Фильтр SLNTools автоматически включает все зависимые проекты, поэтому очень легко создать новое фильтрованное решение.

...