Класс bucketing. ,

Question

Ok, так что я пытался поставить всех один из моих классов в некоторой корневой папке, либо:

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

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

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

2. Event Arg classes?

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

А.

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

или

ProjectX
--BusienssLogic
---- Subsystem1BL
---- Subsystem2BL
--DataAccess
---- Subsystem1DA
---- Subsystem2DA
--BusinessObjects
---- Subsystem1BO
---- Subsystem2BO

или

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

Answer 1

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

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

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

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

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

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

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

C: \ Source Control \ Ядро [Компания] .Core.Data \
C: \ Source Control \ Ядро [ Компания] .Core.Data \ Адаптеры
C: \ Source Control \ Ядро [Компания] .Core.Data \ Кэширование
C: \ Source Control \ Ядро [Компания] .Core.Data \ Преобразователи
C: \ Source Control \ Ядро [Компания ] .Core.Data \ Генераторы

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

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

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

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

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

Answer 2

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

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

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

Answer 3

Существует не один правильный способ сделать это.

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

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

Answer 4

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

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

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

Answer 5

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