Структура проекта для усилий по развитию С#

Какой каталог/решение/структура проекта вы считаете наиболее управляемым и удобным для средних и крупных проектов, написанных на С#? Под "средним до крупным" подразумеваются проекты, которые включают в себя разнообразный набор типов проектов Visual Studio С# в иерархической структуре с вложенными пространствами имен. ¹

Меня интересуют только те типы проектов, которые содержатся в разделе "Windows" в Visual Studio 2008: Windows Forms, WPF, пользовательские элементы управления для библиотек классов и классов. Кроме того, я использую MSBuild (через Visual Studio) для создания моего проекта.

Я никогда не нашел структуру по умолчанию, автоматически создаваемую Visual Studio, которую стоит использовать. Эта структура имеет одну папку исключительно для хранения решения и вложенную папку для каждого проекта. Мне интересно, если это из-за масштаба проекта, в котором я использовал С# в прошлом (от малого до среднего). Какие преимущества имеет эта структура для более крупных проектов? Вы сочли это полезным?

Мне также интересны такие вещи, как имена папок и их отношение к пространствам имен.

Ниже перечислены мои личные цели для структуры проекта.

Цели

Каждый проект должен быть достаточно автономным. То есть, я предпочел бы иметь возможность проверять каждый из них индивидуально и компилировать его (где разрешено зависимостями).
Навигация по структуре должен быть простым.
Структуры каталогов должны быть прозрачными и понятными в пространстве имен.
Идентификация файлов решений должна быть простой.
Проекты должны строить с небольшим или никаким дополнительным усилием в Visual Studio (MSBuild) на большинстве или на всех уровнях иерархии
- Обратите внимание, что мое использование слова "проекты" здесь означает "усилия в области развития", за исключением случаев, когда явно указано.

Ответ 1

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

[logical part name]
  |-doc
  |-lib
     |- // any non-GAC-assemblies needed by the projects in the solution
  |-src
     |-Production
     |  |-Project1
     |  |-Project2
     |-Tests
        |-UnittestProject1
        |-UnittestProject2
  |-tools
     |- // any tools needed for automated builds and such 
        // (NUnit, NCover, MSBuild tasks, ...)

Для этого требуется некоторое перемещение файлов (например, вывод из одной логической части, на которую ссылается другая, должен быть перемещен в эту папку другой части lib), но это можно легко автоматизировать в MSBuild script. У нас также есть такой MSBuild script, который вызывает сценарии MSBuild каждой из логических частей по порядку и перемещает вывод в соответствующие папки lib. Таким образом, я могу создать логическую часть, с которой я сейчас работаю, и сделать сборку всей системы одним щелчком мыши (или, ну, двойной щелчок).

Мы использовали эту структуру в текущем проекте последние полтора года или около того, и, похоже, она работает довольно хорошо.

Ответ 2

Вы можете проверить TreeSurgeon.

Ответ 3

Для проектов С# я обычно использую структуру уровня N. Что-то вроде:

/projectname_interface_layer/ /Projectname _service_layer/ /Projectname _business_layer/ /Projectname _data_layer/

Это имеет то преимущество, что обеспечивает четкое логическое разделение между различными объектами приложения.

Ответ 4

Что мы делаем:

У нас есть отдельные решения, репозитории subversion и сборки для каждого уровня.

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

Каждый слой имеет каталог Lib с внешними ссылками, указывающими на каталоги вывода нижнего уровня.

Перед сборкой любой слой (кроме корневого) будет выполнять обновление во внешних папках, втягивая последние двоичные файлы. Если сборка выполнена успешно, то она обновит внешнюю ссылку на последней версии, а затем проверить его собственные двоичные файлы. Это приведет к следующей постройке цепи и т.д.

Таким образом, разрывное изменение уровня более низкого уровня приведет к сбою в цепочке, но если вы сделаете переход с уровня верхнего уровня, он все равно будет работать при самой последней функциональной регистрации.

Что касается определения слоев, мы в значительной степени имеем уровень фреймворка, уровни бизнес-логики и уровни представления (веб-сервис, приложение или веб-сайт).

Что касается тестов, они должны быть в том же решении, что и те, которые они тестируют, но разных сборках. Испытательные сборки никогда не должны развертываться в производственной среде. Причина в том, что часто, если не всегда, у вас будут свои тестовые сборки как "дружеские" сборки с настоящими. Предполагая, что злоумышленник может выполнять любые публичные элементы в развернутых сборках, это дает им доступ не только к открытым членам вашего реального кода, но и к внутренним.

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