WCF Data Contracts DTO

Question

In my application I am making a service call and getting back populated WCF Data Contract object. I have to display this data in a grid. Is it good practice to bind the data contract to the grid ?

Josh

John, I appreciate your quick response. I am able to display the data successfully in the grid by binding to the data contract. But my question is .. is it good design practice to bind the UI to data contract ? Or should I create another domain object from the data contract and bind the grid to this domain object instead of data contract. I dislike creating duplicate object in the memory. Let me know your thoughts. — Josh, Sep 19 '10 at 00:03

slugster · Answer 1 · 2016-04-11T13:14:59.597

10

Is it good practice to bind the data contract to the grid ?

Yes. There is nothing wrong with what you are doing.

Let me elaborate: what you have received back from the WCF service is a standard object (sometimes referred to as a DTO - Data Transfer Object). You have not received a DataContract - you have received an object that used a DataContract to control the serialization process between the WCF service and your client. The DataContract can control or dictate what you get, but once you have that object you are free to treat it as you wish.

edited Apr 11 '16 at 13:14

answered Sep 19 '10 at 00:25

slugster

49,403
14
95
145

3

Thanks for giving clear distinction in regards with WCF Data Contract and DTOs. – Josh Sep 19 '10 at 03:07

score 2 · Answer 2 · answered Sep 19 '10 at 00:24

Assuming that all of your DTOs are friendly for data binding then shouldn't have a problem binding your WCF DTOs to a grid.

Some scenarios where you might not want to bind directly to your DTOs are:

Your DTOs are not easy to bind with their current definition (e.g. nested objects/properties)
You need to support notification of changes to the binding client (typically done using INotifyPropertyChanged)
You wish to insulate your UI code from changes to the WCF DTOs. This could be because you don't control the DTO definition or you expect frequent changes to the DTO definitions and you don't want to frequently change your UI code. Of course, if the DTO does change then you will have to modify code but you could isolate those changes to a small translation layer.

Thanks slugster and Tuzo. Your response helps a lot... :) – Josh Sep 19 '10 at 03:05 — Josh, Sep 19 '10 at 03:05

score 0 · Answer 3 · answered Jan 13 '16 at 12:15

I'd recommend the use of view models for any data binding or data display (MVVM) on server side (i.e. MVC) and client side (javascrip) rendering.

The main risk of using DTOs returned by domain is that if DTOs are refactored for any reason (i.e. properties are renamed, extracted into other objects or more objects are merged into one) the UI will break and will require update.

DTOs are the contract for what is returned by your domain, whereas the view models are the contract for what the UI requires. The two are controlled by different requirements and although those requirements can be applied to the same set of objects the result is usually a mixture what is just wrong, not to mention that requirements what apply only to UI or domain will trigger changes in the other party.

I.e. views often require data from more DTOs, or different views require a different subset of data from the same DTO and in both cases the DTO should not change only to accomodate what a concrete view requires.

It is also easier to identify what the requirements for a view are if the views have a view model, rather than having the same DTO passed in to more views.

WCF Data Contracts DTO

3 Answers3