Организация кода в отдельных проектах и ​​отдельных пространствах имен

Ответ 1

Я думаю, вы должны разделить свои решения на логические уровни.

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

Пример

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

Это может быть разделено на следующие решения

Back-конец

• Продать модуль: Everyting для продажи вашей продукции
• Купите модуль: покупайте семена, продукты для ваших животных, другие продукты,...
• Модуль планировщика: триггерные события для посева семян, сбор урожая,...
• Модуль прогноза: прогнозирование количества урожая по погоде и рыночных цен,...
• ...

Каждый из этих внутренних модулей может иметь собственный уровень доступа к данным, DTO, службы WCF,...

Это решение будет содержать только Business Logic, Data Access,.... И может быть множество интерфейсных решений, связанных с этими решениями.

Фронтальный

• Приложение ASP.NET MVC: интернет-магазин для продажи потребителю
• Приложение WPF: одобрение продает
• Другое приложение WPF: покупка вещей.
• Мобильное приложение: получение событий на вашем телефоне или что-то в этом роде.
• (Другой вариант - подключить 2 или более бэкэнд-решения к 1 интерфейсу)
• ...

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

Несколько решений будут УВЕЛИЧИТЬ ваше общее время сборки, и важно иметь ночную сборку, чтобы каждый разработчик всегда мог работать с последними двоичными файлами без необходимости создавать все решения на своей локальной машине.

Обратите внимание, что вы все равно можете использовать свои слои в разных решениях:

• Уровень инфраструктуры
• Уровень интеграции (внешние системы)
• Уровень домена
• Уровень репозитория
• Уровень менеджера
• Уровень обслуживания

Чтобы сделать эту работу все вместе и не перепутаться с двоичными файлами. Вы можете отобразить диск I.E. X: где у вас есть двоичные файлы папок, где у вас есть папка для каждого решения. где каждое решение копирует сборки в событии post build. (Script, поэтому он работает на каждой машине)

Если у вас хорошая сетевая инфраструктура, вы также можете скопировать ее на сервер. Поэтому, когда вы строите все решения, например, в TFS, он может скопировать его в место, доступ к которому могут получить все разработчики.

Если вы создаете в TFS, убедитесь, что порядок сборки правильный, сначала самый низкий уровень, последний самый высокий уровень.

Но когда вы разложите свое решение, в решениях вам, вероятно, не понадобятся они в каждом решении.

Недавно я прочитал статью о Onion Architecture, может быть, вы тоже можете это посмотреть. (Он специфичен для ASP.NET MVC).

Вы также можете заглянуть в CQRS.

Ответ 2

Почему 80+ проектов пока у вас всего 6 слоев в вашем приложении?

Вы можете ответить, что они охватывают большое количество функциональных областей, но нужны ли вам все эти функциональные области в одном решении?

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

Ответ 3

Я определенно не буду объединять проекты... Я думаю, что вы быстро получите код спагетти на каждом уровне, поскольку разработчики берут ярлыки (независимо от того, имеют ли они значение или нет), которые они не должны принимать.

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

Я видел, как время сборки уменьшалось, создавая проекты для общего места - видимо, это может помешать VS перестраивать проекты, когда это не нужно, - но я не знаю, верно это или нет.

Некоторые идеи здесь: http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx

Наконец.... это три минуты для полной сборки или только для unit test одного проекта? Сосредоточьтесь на том, что самое большое. Если модульное тестирование занимает много времени, у вас возникла проблема с зависимостями. Если полное решение занимает много времени, получите сервер сборки и сосредоточьтесь на сокращении времени разработки unit test.

Надеюсь, что поможет

Ответ 4

Низкий уровень воздействия. Я столкнулся с такой проблемой, как в прошлом, - создать серию файлов решений, которые включают только один из проектов и его тестовый проект (и, возможно, зависимости от проекта). Затем сделайте себе инструмент, например NCrunch и сделайте большую часть своего кодирования в этих решениях, возможно, используя TDD. Это даст вам молниеносные петли обратной связи и решительно в духе слоистого, развязанного подхода. Когда я это делал в прошлом, я обнаружил, что я на самом деле запускаю все приложение несколько раз в день, максимум, и я сильно полагаюсь на red-green-refactor, что приятно в любом случае.

Если вы хотите, вам даже не нужно контролировать эти небольшие файлы решений - разработчики могут создавать свои собственные, и они могут быть пограничными.

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