Что такое лучшее место для хранения констант в приложении n-ярусов asp.net?

Question

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

Итак, у меня есть приложение с DAL (соединение с базой данных), BLL (бизнес-процессы), объектом Data Transfert «Слой» (классы без каких-либо методов, кроме полей, этот перехватывается всеми остальными) и интерфейсный слой со страницами asp.

Мой вопрос: у меня есть перечисление:

 public enum ID_FOO : uint
 {
     ALL = 1,
     FOOOne= 2,
     FOOTwo= 3
 }

Где я могу положить этот enum (и все остальные), чтобы он был чистым? Не на уровне доступа к данным уровень интерфейса не увидит структуру, не на уровне бизнес-логики, это не совсем бизнес. Может быть, в объекте переноса данных, но действительно ли это «объект переноса»? Должен ли я создать еще один слой ??

Спасибо за все ответы! ..

Answer 1

Я думаю, это зависит от того, какие слои получат доступ к этому struct.

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

Если вы чувствуете, что он не является частью BAL, создайте отдельную сборку (Common), чтобы поделиться такими типами и ссылками на эту сборку. Это будет держать его в чистоте.

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

У нас обычно есть проект библиотеки CompanyName.ProjectName.Core, в котором мы храним наши перечисления, утилиты, константы и т. Д. На эту DLL ссылаются почти в каждом проекте, включенном в это решение.

Answer 6

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

Answer 7

То, что вы показываете, это не структура, а перечисление, которое, как я полагаю, будет использоваться всеми другими слоями и попадет в ваш слой "Transfert".(ПРИМЕЧАНИЕ: я никогда раньше не слышал о трансфертном слое)