Класс ведра. ,

Question

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

UI
BusinessLogic
DataAccess
BusinessObjects
Интерфейсы

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

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

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

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

A.

ProjectX
--Subsystem1
---- BusinessObjects
---- DataAccess
---- BusinessObjects
--Subsystem2
---- BusinessObjects
---- DataAccess
---- BusinessObjects

или

ProjectX
--BusienssLogic
---- Subsystem1BL
---- Subsystem2BL
--DataAccess
---- Subsystem1DA
---- Subsystem2DA
--BusinessObjects
---- Subsystem1BO
---- Подсистема 2BO

или

* * ProjectX тысяча сорок-девять
--BusinessLogic
--DataAccess
--BusinessObjects
(без подкаталогов для каждой функциональной подсистемы)

Answer 1

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

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

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

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

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

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

Имя проекта - это имя корневой папки. Предполагается, что моя папка управления исходным кодом, "C: \ Source Control" на моей локальной машине:

C: \ Source Control \ Core [Company] .Core.Data \
C: \ Source Control \ Core [Company] .Core.Data \ Adapters
C: \ Source Control \ Core [Company] .Core.Data \ Caching
C: \ Source Control \ Core [Company] .Core.Data \ Converters
C: \ Source Control \ Core [Company] .Core.Data \ Generators

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Относительно структуры папок: я бы пошел со вторым, который является 3-х уровневым И держит подсистемы разделенными. Win-Win!

Answer 5

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

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

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