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

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

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

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

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

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

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

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

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

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

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

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

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

xxx.Shell.Exe

xxx.yyyModule.dll (x 4-7)

xxx.Tests

xxx. Model

xxx.Common

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

xxx.Backend

xxx.DataContracts

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

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

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

С точки зрения проектов в рамках решения я использую примерно следующее:

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

Данные - общие данные, такие как XML и т. д. Компилируемый код отсутствует.

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

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

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

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

-Нил

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

В основном так. Как правило, пользовательский интерфейс остаётся компактным, а вся бизнес-логика переносится в отдельный проект (проекты), при этом на каждый проект бизнес-логики приходится один тестовый проект.

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

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

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