Сообщение Re[3]: Зачем нужен DTO? от 13.03.2015 21:29
Изменено 14.03.2015 14:04 artelk
SHE>Здравствуйте, Spinifex, Вы писали:
S>>Вот хорошая ссылка по теме:
SHE>Оттуда: "The only alternative to using DTOs is to reference the domain model assembly from within the presentation layer. In this way though, you establish a tight coupling between layers. And tightly coupled layers may be an even worse problem."
SHE>"Единственной альтернативой использованию DTO является добавление к уровню представления ссылки на доменную модель. Однако в таком случае образуется сильная связанность между уровнями приложения, что является еще худшей проблемой."
Архитектурный онанизм, я считаю. Что плохого в том, что presentation layer будет знать о домене, для представления которого он собственно и создан? А DTO придуман был для решения проблемы производительности при удаленных вызовах. Точка.
Даже главный паттернофил еще в далеком 2004 писал:
http://martinfowler.com/bliki/LocalDTO.htmlDTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls. They are part of implementing a coarse grained interface which a remote interface needs for performance.
...
Some people argue for them as part of a Service Layer API because they ensure that service layer clients aren't dependent upon an underlying Domain Model. While that may be handy, I don't think it's worth the cost of all of that data mapping.
...
So I'd echo Randy's advice "start with a locally invocable Service Layer whose method signatures deal in domain objects. Add remotability when you need it (if ever) by putting Remote Facades on your Service Layer or having your Service Layer objects implement remote interfaces."
...
One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model. In this case it makes sense to make presentation specific facade/gateway that maps from the domain model and presents an interface that's convenient for the presentation. It fits in nicely with Presentation Model.
SHE>Здравствуйте, Spinifex, Вы писали:
S>>Вот хорошая ссылка по теме: _
SHE>Оттуда: "The only alternative to using DTOs is to reference the domain model assembly from within the presentation layer. In this way though, you establish a tight coupling between layers. And tightly coupled layers may be an even worse problem."
SHE>"Единственной альтернативой использованию DTO является добавление к уровню представления ссылки на доменную модель. Однако в таком случае образуется сильная связанность между уровнями приложения, что является еще худшей проблемой."
Архитектурный онанизм, я считаю. Что плохого в том, что presentation layer будет знать о домене, для представления которого он собственно и создан? А DTO придуман был для решения проблемы производительности при удаленных вызовах. Точка.
Даже главный паттернофил еще в далеком 2004 писал:
http://martinfowler.com/bliki/LocalDTO.htmlDTOs are called Data Transfer Objects because their whole purpose is to shift data in expensive remote calls. They are part of implementing a coarse grained interface which a remote interface needs for performance.
...
Some people argue for them as part of a Service Layer API because they ensure that service layer clients aren't dependent upon an underlying Domain Model. While that may be handy, I don't think it's worth the cost of all of that data mapping.
...
So I'd echo Randy's advice "start with a locally invocable Service Layer whose method signatures deal in domain objects. Add remotability when you need it (if ever) by putting Remote Facades on your Service Layer or having your Service Layer objects implement remote interfaces."
...
One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model. In this case it makes sense to make presentation specific facade/gateway that maps from the domain model and presents an interface that's convenient for the presentation. It fits in nicely with Presentation Model.