Каков оптимальный способ организации проекта на C #?

Question

Мне было интересно, как вы, ребята, организовываете свои проекты, с точки зрения функциональности, масштабов и т. Д.

Есть ли у вас один проект для модульных тестов, один проект для кода библиотеки классов, один проект для интерфейса пользователя?

Или вы просто делите все это на отдельные папки?

Я думал, что разделить их по проектам проще, потому что ваша центральная библиотека кода находится в одном месте, без прямых ссылок на UserInterface (без зависимостей WinForms) или UnitTests.

Есть мнения?

Answer 1

Я пытаюсь разделить проекты на то, что вы могли бы назвать «единицами развертывания». Другими словами, «Как я могу развернуть эти сборки?»

Поскольку я, очевидно, не развертываю юнит-тесты, они находятся в их собственном проекте.

Затем я делю пользовательский интерфейс и «бизнес-логику» на отдельные проекты. Если я оставлю эти разделительные линии чистыми, я смогу заменить свой уровень пользовательского интерфейса на новую технологию или инфраструктуру (например, WPF против ASP.NET) и все равно повторно использовать сборки «бизнес-логики» для обоих. Я просто представляю новый уровень пользовательского интерфейса, который понимает интерфейс бизнес-логики.

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

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

Answer 2

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

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

Я всегда стараюсь разделить свою бизнес-логику на один проект (или, скорее, набор проектов), а мой код начальной загрузки / провайдера - на другойпроект (или набор проектов).Мои классы начальной загрузки / провайдера зависят от контекста (они могут предполагать наличие аргументов HttpContext или аргументов командной строки и т. Д.), Но они не содержат бизнес-логики.Мои бизнес-классы реализуют бизнес-логику, но не предполагают наличие или отсутствие каких-либо специфических для контекста элементов.Таким образом, если я изначально создаю систему как консольное приложение, я могу позже написать набор загрузочных / провайдеров службы Windows и очень быстро преобразовать их в службу Windows с минимальным влиянием на бизнес-классы.1005 *

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

Бизнес-логика многих систем слишком сложна, чтобы вписаться в один проект и поддерживать определенную степень сопровождения кода.Таким образом, я обычно оказываюсь с несколькими проектами бизнес-логики, сгруппированными по функциональным областям («управление клиентами», «инвентаризация продуктов» и т. Д.).

Answer 3

Я делаю что-то подобное с точки зрения проектов в рамках решения:

Администрирование - общая документация, основная копия лицензии и т. Д. Обычно я также делаю этот компилятор в небольшой командной строке "Приложение readme ", которое отображает лицензию, примечания к редакции и т. д.

Данные - общие данные, такие как XML и т. д. Нет компилируемого кода.

Library1 ... LibraryN - один или несколькобиблиотеки (обычно 1-3: утилиты, ядро, расширенный код).

Приложение1 ... ПриложениеN - Приложение (обычно одно).

Test1 ... TestN - Тесты.

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

-Neil

Answer 4

Последние несколько проектов, в которых я принимал участие - мы получили следующую структуру (все проекты WPF Prism):

xxx.Shell.Exe

xxx.yyyModule.dll (x 4-7)

xxx.Tests

xxx.Model

xxx.Common

А для тех, кто использует WCF - добавьте:

xxx.Backend

xxx.DataContracts

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

Answer 5

Выполните поиск в Stack Overflow и в Google - есть другие, которые задавали один и тот же вопрос.

Некоторые соображения:

Visual Studio требуется больше времени для компиляции решений со многими проектами,чем отдельные крупные проекты.Не разделяйте ваше решение слишком тонко.

Руководство Microsoft по составным приложениям предлагает интересный способ разделения проектов.Есть проект инфраструктуры, проект начальной загрузки, а затем проекты для каждого «модуля» кода.

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

Я предпочитаю организовывать файлы по назначению, а не по типу.Например, я создаю папки с именами «Связь» и «Взаимодействие», а не «События» и «Интерфейсы».

Answer 6

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

Конечно, MVC - это просто общая концепция, но она помогаетвы принимаете решения, с которыми вы сталкиваетесь прямо сейчас.

В MVC WPF есть много ресурсов, которые вы, вероятно, также можете применить непосредственно к WinForms.

Answer 7

У вас есть один проект на единицу тесты, один проект для библиотеки классов код, один проект для пользовательского интерфейса?

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

Answer 8

Я разбиваю проекты по типу сборки, как вы описали. Хорошо иметь хотя бы основной исполняемый проект (если это приложение) и одну или несколько библиотек классов. Если это приложение для Windows, постарайтесь как можно больше отделить пользовательский интерфейс от кода. Приложения WPF прекрасно справляются с этой задачей.

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