Просто добавив мои 2 цента к этому вопросу, чтобы расширить ответ Джона с некоторым опытом "был там - сделал это":
Я использовал в нескольких решениях, по крайней мере, два проекта, названных пространством имен (ну, вроде). Например, работая над решением MyApp, я бы получил MyApp.Web и MyApp.Web.Controls.
Или: MyApp.Service, MyApp.Core, MyApp.Core.Entities и так далее. Довольно известное соглашение об именах, где корневое пространство имен выглядит как MyCompany.MyApp.Service etc...
Преимущество :
- нашел его очень полезным при работе в команде, чтобы выделить зависимости между модулями приложения. Если ваш Web.Controls модуль (это всего лишь пример, не выбирайте его :) доступен для общего доступа через веб-интерфейс, вы обычно не хотите, чтобы специфичный для приложения код использовался в ваших пользовательских элементах управления. Хранение модуля child / nested отдельно (на которое ссылается основной проект) обеспечивает это.
- по крайней мере, если подумать, это поможет вам создать лучшую структуру проекта. Какое пространство имен входит в отдельный проект, а какое нет? Ответ на один вопрос достаточно полезен.
Неудобство :
- очень легко получить «триггер» и создать сотню проектов вместо создания соответствующих папок / пространств имен.
Тем не менее, обычно имеют тенденцию создавать папки вместо отдельных проектов, за исключением случая, когда это действительно "подмодуль".