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

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

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

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

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

Спасибо

Ответ 1

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

Sln
- Sln.Core
- Sln.Core.Test
- Sln.Datali >
- 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 и т.д. для проектов, которые он содержит. Кажется, что это облегчает работу со всеми ссылками.

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