Прохождение бизнес-сущностей через уровни в многоуровневой архитектуре

В настоящее время я работаю над проектом, использующим многоуровневую архитектуру, как описано в Руководстве по архитектуре приложений 2.0 с 5 уровнями (DAL , BLL, Facade, Presentation Layer и Common Layer).
Здесь у нас есть уровень бизнес-логики, который состоит из бизнес-компонентов и бизнес-сущностей (которые являются сущностями, сгенерированными с помощью O / R Mapper), нам регулярно нужны эти сущности в нашем уровень представления для привязки и представления данных пользователю, поэтому мы переносим эти сущности на уровень представления через другие уровни.

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

Приветствуются любые разъяснения.


architecture entities architectural-patterns business-logic-layer
person VahidNaderi    schedule 06.03.2013    source источник
comment
Вот серия, которая может быть интересной относительно сущностей домена и того, где их разместить: ludwigstuyck.wordpress.com/2013/03/05/   -  person L-Four    schedule 09.03.2013

Ответы (2)


arrow_upward
3
arrow_downward

Правильно многоуровневое приложение обычно использует DTO для предотвращения фальсификации и искажения бизнес-сущностей, среди прочего, для удовлетворения потребностей других уровней.

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

У Марка Зеемана есть интересная запись в блоге по этой проблеме.

person guillaume31    schedule 07.03.2013
comment
Спасибо за ссылку, очень интересно. - person VahidNaderi; 08.03.2013

arrow_upward
1
arrow_downward

Держите свои бизнес-объекты только на бизнес-уровне. Поначалу DTO могут показаться избыточными, но по мере роста проекта вы начнете замечать различия между ними: DTO гораздо более плоские, типы и сущности, удобные для сериализации, имеют гораздо более сложные отношения и возможности, они несут больше логики приложения, чем DTO.

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

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

person Kimi    schedule 07.03.2013