Советы по разделению проектов в .NET

Question

Я ищу несколько советов по разделению проектов в .NET. Я создаю большое приложение для форм Windows (80 таблиц), и у меня есть только несколько проектов. Они становятся довольно большими. Я заметил проблему, когда увидел список ссылок на днях. Я впервые создаю такое большое приложение, поэтому названия проектов и их разделение становятся немного запутанными.

Вот что у меня есть, и проблемы каждого проекта.

ProjectName.Dal (доступ к данным, это автоматически сгенерировано для меня, я не касаюсь этого.)

ProjectName.Bll (репозитории, общение с веб-сервисами, создание электронных писем, создание документов Excel и Word)

ProjectName.Model (доменные объекты)

ProjectName.UI (формы Windows и пользовательские элементы управления)

ProjectName.UI.Web (некоторые веб-страницы для небольшого веб-интерфейса для системы)

ProjectName.UI.Controls (общие пользовательские элементы управления окнами)

ProjectName.UI.Presenters (пара докладчиков для форм MVP)

ProjectName.Reminder (веб-сервис для приложения, которое напоминает людям делать что-то)

ProjectName.Tests (обрабатывать все модульные тесты) - я не уверен, должен ли каждый проект иметь тестовый проект, например, ProjectName.UI.Presenters.Tests

Answer 1

Одна вещь, которую я хотел бы выделить как отдельную сборку из тех, что вы уже упомянули, это проект «прокси».

Предположим, вы используете один из ваших веб-сервисов на уровне презентации. Вместо прямой ссылки на сервис (wcf / .asmx) на уровне представления, я хотел бы иметь отдельный проект, посвященный инкапсуляции прокси для этого сервиса. У меня обычно есть класс-оболочка вокруг самого прокси, чтобы помочь управлять сбоями и обеспечить, чтобы прокси всегда был доступен для уровня представления (или давать хорошие исключения, если нет), а также предоставлять хорошие объекты уровня представления из прокси. Например, я мог бы хотеть передать Widget [] вместо DataTable виджетов из моего сервиса на мой прокси, чтобы сделать все это красивым и SO-совместимым (очевидно, мы не хотим передавать DataTables из сервиса, так как они все но непонятно на уровне .xsd) Но DataTables хорошо связывать на уровне представления, поэтому я обертываю фактический прокси, который получает этот виджет [], с помощью 'managedProxy', который выполняет преобразование из массива в DataTable, а также управляет вызовом прокси Имея это разделение прокси от уровня представления на уровне класса, затем продвигается дальше, внедряя его в свой собственный проект. Это делает его более портативным для перехода на следующий уровень в настоящий момент.

Answer 2

Насколько я могу сказать, это слишком большое разделение.

Я думаю, что лучшая структура будет выглядеть примерно так:

• ProjectName.Dal
• ProjectName.Bll
• ProjectName.Model
• ProjectName.UI
• ProjectName.Reminder

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

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

Answer 3

используйте папки в проектах для дальнейшего разделения ваших классов от друг друга в зависимости от домена. Кроме того, вы можете создавать папки решений в Visual Studio, это виртуальные папки, которые можно использовать для группировки проектов внутри вашего решения. Щелкните правой кнопкой мыши на решении в обозревателе решений и создайте в качестве примера папку для тестирования, и вы можете поместить туда тестовые проекты, настроить проекты в другой и т. Д. И т. Д. Вы также можете разбить другие домены .