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
A data contract is a formal agreement between a service and a client that abstractly describes the data to be exchanged. That is, to communicate, the client and the service do not have to share the same types, only the same data contracts.
FaultContract inherits from the FaultContractAttribute Class. Create a table named EMPLOYEE with column names EMP_ID and EMP_NAME. We will create a service to input the user id and get the name of the employee. Step 2: Open Visual Studio then select "File" -> "New" -> "Project..." -> "WCF" -> "WCF Service Application".
Data Contracts can be defined as follows: It describes the external format of data ed to and from service operations. It defines the structure and types of data exchanged in service messages. It maps a CLR type to an XML Schema. It defines how data types are serialized and deserialized.
Data Member are the fields or properties of your Data Contract class. You must specify [DataMember] attribute on the property or the field of your Data Contract class to identify it as a Data Member. DataContractSerializer will serialize only those members, which are annotated by [DataMemeber] attribute.
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 - D
ata T
ransfer O
bject). 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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With