Как организовать .NET-решения, проекты и системные папки для нескольких приложений? - PullRequest
Новая
       32

Как организовать .NET-решения, проекты и системные папки для нескольких приложений?

3 голосов
/ 14 октября 2010

У нас много проблем с организацией наших решений. У нас есть несколько приложений. Это похожие приложения, поэтому много повторного использования. Различные приложения включают разные возможности в зависимости от того, за что заплатят наши разные клиенты.

Итак, как нам организовать вещи? MSDN говорит организовать следующим образом: 

SolutionFolder\
               Proj1Folder\
               Proj2Folder\
               Proj3Folder\ ...

(Примечание. Под папкой решения я подразумеваю фактическую папку в системе, а не папку решения Visual Studio.)

Но не сообщается никаких подробностей относительно нескольких решений, которые повторно используют проекты. Не имеет смысла создавать вторую папку решения и ссылочные проекты в первой папке решения. Моя первая мысль - полностью изолировать решения, а затем ссылаться на проекты по мере необходимости. Имеет ли это смысл? Смотрите ниже: 

Solutions\
          Solution1.sln
          Solution2.sln
          Solution3.sln
Projects\
         AFeatures\
                   AProject1\
                   AProject2\
                   AProject3\
         BFeatures\
                   BProject1\
                   BProject2\
         CFeatures\
                   CProject1\
                   CProject2\

В приведенном выше примере я сгруппировал проекты на основе определенных функций. Solution1 может включать в себя функции A и C, Solution2 может включать в себя функции B и C, а Solution3 может включать в себя A и B. Вещи усложняются, потому что каждая функция может иметь подфункции, которые будут не во всех решениях. Другими словами, могут быть общие AFeatures, но затем более специфичные A-1Features, A-2Features и т. Д.

Кроме того, мы также хотели бы сгруппировать наши проекты на основе n-уровневой архитектуры. Итак, я полагаю, что мы бы добавили также папки BusinessServices, DataServices и UserServices. Но имеет ли смысл размещать папку n-уровня выше или ниже структуры функций? Здесь мой мозг начинает вращаться.

На аналогичной ноте мы хотели бы иметь наши интерфейсы в разных проектах, которые реализуются. Это может быть не так уж важно. Я предполагаю, что у нас будут AInterfacesProject1 и AProject на одном уровне каталогов, поэтому они близко друг к другу.

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

1 Ответ

1 голос
/ 15 октября 2010

Все, что я могу вам сказать, это как я организовываю свои проекты.

У меня есть ASP.NET CMS / Framework;он состоит из 3 основных решений: 

MyCode.Core (sln)
  \MyCode.Core.Common (proj)
  \MyCode.Core.BusinessLogic
  \MyCode.Core.IDataprovider 
  \etc...

MyCode.Core sln - единственное место, где я занимаюсь (серьезной) разработкой этих проектов.Я копирую успешные сборки в «нейтральное» место на диске.

В него включены копии ссылок на проекты dll (MS Ent Libs, библиотека AntiXSS).

Далее у меня есть проекткоторый является своего рода SDK для "скинов и шаблонов".

MyCode.Templates (sln)
  \MyCode.Templates.Nasqueron (proj)

Вывод этого проекта копируется в то же нейтральное место, что и ядро.Этот проект ссылается на результаты проектов MyCode.Core, особенно те, которые хранятся в нейтральной папке.

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

Таким образом, в основном мой подход таков:

  • Позволяет редактировать проекты только в рамках одного решения (в основном - принять решение окто «владеет» проектом).
  • копировать / развертывать стабильные копии в нейтральном месте, которое находится за пределами фактической структуры файла решения / проекта, и ссылаться на эти копии общего кода.
...