Типичная структура решения ASP.NET?

Как гласит название, мне интересно узнать, как вы обычно структурируете решения ASP.NET.

Меня особенно интересуют решения ASP.NET WebSite, но информация может быть интересна и другим типам (WebApplication, MVC).

Некоторые конкретные вопросы:

  • что/сколько проектов/сборок содержит решение
  • как вы называете проекты библиотеки классов.
  • какие пространства имен у вас обычно есть
  • У вас есть несколько пространств имен для каждого проекта/сборки или у вас есть строгая связь 1:1.
  • и др.

Спасибо

Ответы

Ответ 1

Один из моих проектов выглядит так:

  • Sln
    • Sln.Core
    • Sln.Core.Test
    • Sln.Data​​li >
    • Sln.Data.Test
    • Sln.Web
    • Sln.Web.Test

Core - это модель домена и сервисы домена, насколько это возможно, без перехода на постоянство. Данные - это уровень персистентности, который в основном означает определения FluentNHibernate и конкретные реализации интерфейсов, определенных в Core. Веб - это интерфейсный слой.

Ответ 2

Я сделал нечто похожее на Правосудие. Но с меньшим количеством проектов (и более быстрым временем компиляции)

Sln

  • Project.Core
  • Project.Web
  • Project.Test

Project.Core будет выглядеть следующим образом

  • Repository
  • Домен
  • Presenter
  • Сервис
  • Вид
  • Общие

Я не получаю выгоду от нескольких (более 3) проектов. Вы не получаете testablility, и ваше время компиляции становится намного дольше.

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

Ответ 3

Обычно я использую имя приложения для имени решения (используя общий тип проекта "Решение" ), а затем создайте SolutionName.Site, SolutionName.Domain, SolutionName.Persistence и т.д. для проектов, которые он содержит. Кажется, что это облегчает работу со всеми ссылками.

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