Структурирование файлов в .NET-проекте

Question

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

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

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

Глядя на исходный код Microsoft на GitHub Я вижу, что интерфейсы и их реализации, как правило, находятся в одном каталоге и что, хотя группировка файлов существует, она не выполняется на основе конструкции языка. Мне трудно точно определить, что такое стратегия группировки.

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

Answer 1

Я думаю, вы обнаружите, что большинство проектов пытаются: 1) держать вещи вместе, которые принадлежат друг другу (например, перечисления, которые используются определенным набором классов, группируются не в папку enums, а в папке с этими классами), и 2), чтобы поместить вещи в структуре, которая имитирует их иерархию пространства имен (так же, как ваша модель пространства имен будет MyProject.Areas.MyArea.Models в проекте MVC, и Areas, MyArea и Models все вложенные папки.

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