WCF Data Contracts DTO

Question

В моем приложении я звоню в сервис и получаю обратно заполненный объект контракта данных WCF Я должен отобразить эти данные в сетке. Это хорошая практика, чтобы связать контракт данных с сеткой?

Josh

Answer 1

Это хорошая практика, чтобы связать контракт данных с сеткой?

Да. Нет ничего плохого в том, что вы делаете.

Позвольте мне пояснить: то, что вы получили от службы WCF, является стандартным объектом (иногда его называют DTO - D ata T перевод O bject). Вы не получили DataContract - вы получили объект, который использовал DataContract для управления процессом сериализации между службой WCF и вашим клиентом. DataContract может контролировать или определять то, что вы получаете, но как только у вас есть этот объект, вы можете обращаться с ним как хотите.

Answer 2

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

Некоторые сценарии, в которых вы можете не связывать напрямую с вашими DTO:

• Ваши DTO нелегко связать с их текущим определением (например, вложенные объекты / свойства)

• Вам необходимо поддерживать уведомление об изменениях в клиенте привязки (обычно это делается с помощью INotifyPropertyChanged)

• Вы хотите оградить свой код пользовательского интерфейса от изменений в DTO WCF. Это может быть связано с тем, что вы не контролируете определение DTO или ожидаете частых изменений в определениях DTO и не хотите часто менять свой код пользовательского интерфейса. Конечно, если DTO действительно изменится, вам придется изменить код, но вы можете изолировать эти изменения в небольшом слое перевода.

Answer 3

Я бы рекомендовал использовать модели представления для любой привязки данных или отображения данных (MVVM) на стороне сервера (т.е. MVC) и на стороне клиента (javascrip).

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

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

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

Также легче определить требования к представлению, если представления имеют модель представления, а не передают один и тот же DTO в другие представления.