Классовое группирование..

Question

Хорошо, я пытался поместить каждый из моих классов в какую-нибудь корневую папку:

пользовательский интерфейс
БизнесЛогика
Доступ к данным
БизнесОбъекты
Интерфейсы

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

1. Класс Cache, который поддерживает частный словарь и обеспечивает различный доступ к объектам на основе определенных ключей.

2. Классы событий Arg?

Кроме того, в рамках проекта у меня теперь появляются подсистемы, имеющие все три (доступ к данным, бизнес-объекты, бизнес-логика).Как мне разбить структуру папок?

А.

Проект Икс
--Подсистема1
----БизнесОбъекты
----Доступ к данным
----БизнесОбъекты
--Подсистема2
----БизнесОбъекты
----Доступ к данным
----БизнесОбъекты

или

Проект Икс
--BusienssLogic
----Подсистема1BL
----Подсистема2BL
--Доступ к данным
----Подсистема1DA
----Подсистема2DA
--БизнесОбъекты
----Подсистема1BO
----Подсистема2BO

или

Проект Икс
--БизнесЛогика
--Доступ к данным
--БизнесОбъекты
(без подкаталогов для каждой функциональной подсистемы)

Answer 1

Я стараюсь согласовать имена своих сборок с их пространствами имен и использовать саму .NET Framework в качестве ориентира.Я твердо верю, что работа со структурой пространства имен, управляющей структурой папок, позволяет сделать базу кода гораздо более удобной для сопровождения.

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

[Компания].Core.Data.Caching

У меня есть другие функции, связанные с данными, которые также логически подпадают под функцию «Данные», поэтому у кэширования есть родственные элементы, такие как адаптеры, преобразователи и генераторы.Итак, предположим, что у нас есть следующие пространства имен:

[Компания].Core.Data.Адаптеры
[Компания].Core.Data.Converters
[Компания].Core.Data.Caching
[Компания].Core.Data.Generators

Эти связанные пространства имен находятся в сборке под названием [Company].Core.Data, которая также является именем проекта.Следуя этой структуре, поиск вещей в решении становится очень простым.Говоря о структуре, теперь вернемся к тому, как они хранятся на диске.

Имя проекта — это имя корневой папки.Предполагается, что моя папка управления версиями — «C:\Source Control» на моем локальном компьютере:

C:\Source Control\Core[Компания].Core.Data\
C:\Source Control\Core[Компания].Core.Data\Адаптеры
C:\Source Control\Core[Компания].Core.Data\Caching
C:\Source Control\Core[Компания].Core.Data\Converters
C:\Source Control\Core[Компания].Core.Data\Generators

Итак, в виде иерархии это выглядит примерно так:

[Решение]
--[Компания].Core.Data
----[Адаптеры]
------(файлы адаптеров)
----[Кэширование]
------(Кэширование файлов)
----[Конвертеры]
------(Конвертеры файлов)

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

Я делаю это уже много лет, и это очень удобно не только мне, но и моим разработчикам.

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

Answer 2

Обычно мне нравится придерживаться правила «1 класс — 1 файл», но когда дело доходит до EventArgs, мне на самом деле нравится объявлять их в том же файле, в котором я определяю делегата или событие.Если только аргументы не используются более чем одной иерархией классов, что случается со мной нечасто.

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

Как бы мне ни нравилась хорошая организация, с ней можно слишком заморачиваться.

Answer 3

В основном это личный вкус.

Я согласен с тем, что Брайан Дженизио сказал относительно того, где разместить классы EventArg и т.д.:если вы используете их только один раз, поместите их в тот же файл, где вы их используете.Для общих занятий/файлов у меня всегда есть папка «Общие» (как удобно!;-))

Что касается структуры папок:Я бы выбрал второй, трехуровневый И сохраняет подсистемы разделенными.Беспроигрышный вариант!

Answer 4

Я просто хочу добавить комментарий к именам.Я считаю, что слово «бизнес» приводит к неправильному использованию.Мы сделали это, и теперь не знаем, о чем речь:логика предметной области или уровень обслуживания.Я бы предложил имена, как домен.Domain.impl (для отделения интерфейсов от IMP), а затем услуг ... и, возможно, настойчивости, если вы используете ORM ... это может быть иначе, если вы используете другой подход, но, честно и бизнесобъекты.Я не понимаю, что к чему.BusinessObjects должен содержать бизнес-логику, логично?Или это просто DTO?Тогда почему они находятся в отдельном от DataAccess проекте?

Answer 5

Не существует единственного правильного способа сделать это.

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

Извините, я пропустил тег C#.Примеры хороших проектов .NET уже рассматривались ранее. здесь и здесь.