4

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

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

Любые разъяснения были бы оценены.

+1

Вот серия, которая может быть интересна в отношении сущностей домена и где их разместить: http://ludwigstuyck.wordpress.com/2013/03/05/a-reference-architecture-part-1 –

ответ

3

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

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

Mark Seemann имеет интересный blog post по этой проблеме.

+0

Спасибо за ссылку, очень интересно. – VahidNaderi

+0

+1: для ссылки. – Ashkan

1

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

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

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