Есть сущность, которая в базе имеет порядка 10 полей. Клиенту на сайт надо возвращать порядка 3.
Обычно все книжки учать оборачивать в DTO.
А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

Здравствуйте, peer, Вы писали:

P>Обычно все книжки учать оборачивать в DTO.
P>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

А IEnumerable<Object> зачем? Возвращайте просто object, чего уж там?!

Здравствуйте, Tissot, Вы писали:

T>Здравствуйте, peer, Вы писали:

P>>Обычно все книжки учать оборачивать в DTO.
P>>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

T>А IEnumerable<Object> зачем? Возвращайте просто object, чего уж там?!

на клиенте сложней будет парсить

Здравствуйте, peer, Вы писали:


P>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

Вы это серьезно?

Здравствуйте, peer, Вы писали:

P>Есть сущность, которая в базе имеет порядка 10 полей. Клиенту на сайт надо возвращать порядка 3.
P>Обычно все книжки учать оборачивать в DTO.
P>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

Во многих приложениях с которыми мне приходилось иметь дело Dto действительно не нужны.
Они лишь усложняют положение дел не привнося никакой пользы.
Вот хорошая ссылка по теме:
Зачастую на клиент проще/лучше передавать непосредственно сущности.

Здравствуйте, Spinifex, Вы писали:

S>Здравствуйте, peer, Вы писали:

P>>Есть сущность, которая в базе имеет порядка 10 полей. Клиенту на сайт надо возвращать порядка 3.
P>>Обычно все книжки учать оборачивать в DTO.
P>>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

S>Во многих приложениях с которыми мне приходилось иметь дело Dto действительно не нужны.
S>Они лишь усложняют положение дел не привнося никакой пользы.
S>Вот хорошая ссылка по теме:
S>Зачастую на клиент проще/лучше передавать непосредственно сущности.

тоже думал, но там хранится системная инфа, кто и когда создал

Здравствуйте, peer, Вы писали:

S>>Во многих приложениях с которыми мне приходилось иметь дело Dto действительно не нужны.
S>>Они лишь усложняют положение дел не привнося никакой пользы.
S>>Вот хорошая ссылка по теме:
S>>Зачастую на клиент проще/лучше передавать непосредственно сущности.

P>тоже думал, но там хранится системная инфа, кто и когда создал

Если это системная инфа, может она там не должна хранится все таки?

Здравствуйте, Spinifex, Вы писали:

S>Во многих приложениях с которыми мне приходилось иметь дело Dto действительно не нужны.
S>Они лишь усложняют положение дел не привнося никакой пользы.
S>Вот хорошая ссылка по теме:

Оттуда: "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."

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

Здравствуйте, Spinifex, Вы писали:

S>Здравствуйте, peer, Вы писали:

S>>>Во многих приложениях с которыми мне приходилось иметь дело Dto действительно не нужны.
S>>>Они лишь усложняют положение дел не привнося никакой пользы.
S>>>Вот хорошая ссылка по теме:
S>>>Зачастую на клиент проще/лучше передавать непосредственно сущности.

P>>тоже думал, но там хранится системная инфа, кто и когда создал

S>Если это системная инфа, может она там не должна хранится все таки?

есть дата создания заказа и кто ее создал. где ее предлагаете хранить? дату создания иногда надо показывать на сайте

Здравствуйте, peer, Вы писали:

P>Есть сущность, которая в базе имеет порядка 10 полей. Клиенту на сайт надо возвращать порядка 3.
P>Обычно все книжки учать оборачивать в DTO.
P>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

Потому что на сервере к сущностям могут быть привязаны некие методы, которые исплнять можно только на сервере. Вызвал такое на клиенте и внезапно получил загадочный exception. Положим, вы все помните, что где можно вызывать. А если к проекту подключатся еще люди?

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

Сущности, с которыми работает клиент и сущности базы могут начать отличаться со временем. Без DTO вы при изменениях в базе будете вынуждены менять контракт между клиентом и сервером. А что делать старым клиентам, которых нет возможности обновить?

Здравствуйте, SHEMA, Вы писали:

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 писал:

DTOs 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.

http://martinfowler.com/bliki/LocalDTO.html

Здравствуйте, artelk, Вы писали:

A>http://martinfowler.com/bliki/LocalDTO.html

Минусовавшие не согласны со статьей Фаулера или с чем-то еще? Можно развернуть?

Здравствуйте, artelk, Вы писали:

A>Архитектурный онанизм, я считаю. Что плохого в том, что presentation layer будет знать о домене, для представления которого он собственно и создан? А DTO придуман был для решения проблемы производительности при удаленных вызовах. Точка.
A>Даже главный паттернофил еще в далеком 2004 писал:
A>( ... )
A>Минусовавшие не согласны со статьей Фаулера или с чем-то еще? Можно развернуть?

Я думаю конфуз в том, что топикстартер задавал вопрос о DTO применительно к модели данных (объекты-сущности).
А Фаулер писал о DTO применительно к доменной модели, имея ввиду: Data model -> Domain model -> DTO -> View model.
И в этом случае, использование DTO действительно не всегда оправдано.

Здравствуйте, Слава, Вы писали:


С>Потому что на сервере к сущностям могут быть привязаны некие методы, которые исплнять можно только на сервере.
А вот не надо к сущностям методы привязывать. =) Тогда и остальных проблем не будет.
А то сначала сделают проблему на ровно месте, а потом решают ее.. через DTO.

Здравствуйте, IB, Вы писали:

IB>А то сначала сделают проблему на ровно месте, а потом решают ее.. через DTO.

Как я писал, в проекте могут быть еще люди, на которых невозможно повлиять.

Здравствуйте, Слава, Вы писали:


С>Как я писал, в проекте могут быть еще люди, на которых невозможно повлиять.
Не бывает таких людей... Бывают неправильные процессы.

Здравствуйте, Слава, Вы писали:

IB>>А то сначала сделают проблему на ровно месте, а потом решают ее.. через DTO.
С>Как я писал, в проекте могут быть еще люди, на которых невозможно повлиять.

Тогда при чём тут DTO?

Здравствуйте, peer, Вы писали:

P>Есть сущность, которая в базе имеет порядка 10 полей. Клиенту на сайт надо возвращать порядка 3.
P>Обычно все книжки учать оборачивать в DTO.
P>А зачем это делать если можно вместо IEnumerable<MyDTO> возвращать IEnumerable<Object> ?

А зачем тогда писать сервер, если он не нужен? Клиент удалённо подключается к серверу БД, забирает нужные объекты.