Где разместить бизнес-объекты, перечисления, пользовательские исключения?

Question

Я пытаюсь выяснить, как делиться своими сущностями между уровнями данных, бизнеса и пользовательского интерфейса. Лучше ли создать отдельный проект для этих объектов, на который будут ссылаться все уровни? Как насчет Enums и пользовательских исключений? У меня есть некоторые перечисления, используемые только проектом пользовательского интерфейса, и некоторые, используемые Бизнесом. Означает ли это, что у меня должно быть две отдельные папки Enum: одна в бизнес-проекте и одна в пользовательском интерфейсе? Точно так же с исключениями? До сих пор я поддерживал сущности, перечисления и исключения в одном отдельном проекте, на который ссылаются все 3 уровня.

В проекте «Мой бизнес» есть классы Manager (например, ProductManager.cs), в которых есть методы, такие как List GetProducts (), SaveProduct (Product) и т. Д.

Answer 1

Подумайте об инкапсуляции. Поместите их в область, где они необходимы, а не в более широкую область.

Если что-то используется только на уровне пользовательского интерфейса, не открывайте его другим слоям. Но если он используется на двух или трех уровнях, то определите его на уровне самого низкого уровня (например, если пользовательский интерфейс расположен в бизнес-логике, которая находится в базе данных, то что-то, используемое в BL и пользовательском интерфейсе, можно просто определить в BL). Или, если что-то более или менее глобально, переместите его в стороннюю общую библиотеку.

Кроме того, в первую очередь постарайтесь свести к минимуму потребность в общих сущностях: например, Рекомендуется (по уважительным причинам) избегать пользовательских исключений. Большинство из них обычно могут быть представлены в существующем системном исключении с небольшим количеством дополнительной информации (например, InvalidOperationException с подробностями в сообщении), сводя к минимуму необходимость обрабатывать целый новый класс исключений повсюду - и, конечно, устраняя необходимость принимать решение где определить тип пользовательского исключения.

Answer 2

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

Answer 3

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

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

В зависимости от того, что вы делаете, не может быть вреда сохранение типов, специфичных для слоя, в том же проекте / сборке, что и ваши общие типы, но я бы рекомендовал ограничить их собственным слоем.

Answer 4

Если вам нужны сущности на всех уровнях, то лучше использовать отдельный проект (imo).

Answer 5

Обычно я помещаю перечисления и пользовательские исключения вместе с определениями интерфейса в отдельный проект.