locked
ASP.NET Data Binding w/ WCF Services RRS feed

  • Question

  • I’m working on an application in which I have a WCF service which provides data to a SharePoint WebPart. The generally accepted best practices for WCF suggest that you shouldn’t send an object like a DataSet or a DataTable over the wire. The reason for this seems to be based on two key factors: performance and interoperability. In my particular case, interoperability is not a huge concern. I have Windows on both ends and there is no expectation to use this service for other systems. As to the performance thing, honestly, I never ran into performance issues sending datasets in the past on projects/solutions of this size and limited scope.

     

    This is a “quick-and-dirty” implementation and my hope is that I could leverage a lot of the built in data binding features to save a lot of leg work. The issue is, many of the UI controls which are part of ASP.Net really want to get a DataSet or a DataTable. Sure, they will bind to a collection of objects, but when you do that there is no support for a lot of the  functionality baked in such as filtering and sorting. Even when you use an ObjectDataSource, the expectation is that, in order to use all the nice stuff, the object returned will be a DataSet or DataTable. It seems like it would be really nice if I could just take my strongly typed collection that comes back from my WCF service and convert it to one of these types efficiently.

     

    Is it really that bad to send a DataSet / Table over the wire with WCF if interoperability is not a huge concern?

     

    Am I approaching the whole data binding thing wrong? Is there something I’m overlooking that will let me do what I want to do? Admittedly, I am fairly new to WCF. I know that I can write code to fully support binding in my objects but my whole point here is to be able to rapidly leverage the out of the box stuff.


    Thanks in advance 


    Dan

    Sunday, August 24, 2008 3:01 PM

Answers

  • Hi,

     

    Besides the two issues with using DataSets over WCF, which you already mentioned, that they are preventing interoperability and they reduce the performance, there is another issue, which you should consider, when using DataSets - the way they are serialized.

    As you might know, WCF initially aupported three methods of serializing\deserializing objects:

    • We support serialization of objects implement the ISerializable interface (or attributed with the SerializableAttribute).
    • We support serialization of objects attributed with DataContract\DataMembers, provided as part of the new serialization model introduced as part of NetFx 3.0
    • We support serialization of objects implementing the IXmlSerializable interface.

    As part of Orcas SP1, we've added support of a new mode of serialzation - supporting POCO (Plain Old C# Objects) serialization.

     

    The serialzation of DataSets is based on the fact that these objects implement the IXmlSerializer interface; simply speaking, the serialization of these objects is implemented in the objects themselves. This is why they introduce performance penalty, because we cannot generate the efficient serialization code, we are generating for the other modes of serialization.

    This fact has another side-efect - an object implementing the IXmlSerializer interface can provide us, optionally, its schema. This is not a requirement, yet without the schema we treat this object as a big blob of XML. Well, as you can probably guess, DataSets has opted out of providing us the schema, as a result our generated proxy is more limited; also our tooling lacks as well.

     

    To summerize, you can use DataSets with WCF; it is not recomended, however.

     

    Regards,

     

    Oren Fisher

    Microsoft, Connected Frameworks

     

    Monday, August 25, 2008 9:41 PM

All replies

  • Hi,

     

    Besides the two issues with using DataSets over WCF, which you already mentioned, that they are preventing interoperability and they reduce the performance, there is another issue, which you should consider, when using DataSets - the way they are serialized.

    As you might know, WCF initially aupported three methods of serializing\deserializing objects:

    • We support serialization of objects implement the ISerializable interface (or attributed with the SerializableAttribute).
    • We support serialization of objects attributed with DataContract\DataMembers, provided as part of the new serialization model introduced as part of NetFx 3.0
    • We support serialization of objects implementing the IXmlSerializable interface.

    As part of Orcas SP1, we've added support of a new mode of serialzation - supporting POCO (Plain Old C# Objects) serialization.

     

    The serialzation of DataSets is based on the fact that these objects implement the IXmlSerializer interface; simply speaking, the serialization of these objects is implemented in the objects themselves. This is why they introduce performance penalty, because we cannot generate the efficient serialization code, we are generating for the other modes of serialization.

    This fact has another side-efect - an object implementing the IXmlSerializer interface can provide us, optionally, its schema. This is not a requirement, yet without the schema we treat this object as a big blob of XML. Well, as you can probably guess, DataSets has opted out of providing us the schema, as a result our generated proxy is more limited; also our tooling lacks as well.

     

    To summerize, you can use DataSets with WCF; it is not recomended, however.

     

    Regards,

     

    Oren Fisher

    Microsoft, Connected Frameworks

     

    Monday, August 25, 2008 9:41 PM
  • Hey Oren,

     

    Thanks for the response. I understand what you are saying. Idealy, I would like to get away from datasets. Based on this, what course of action would you recomend to me? Keep in mind, my end goal is to allow the WCF cleint application, which is a web part running in Microsoft SharePoint, to consume data from the WCF service in such a way that I have to employ minimal effort to bind it to ASP.Net UI control (in this case specificly a SPGridView).  

     

    In my particular example I'm dealing wiht a custom issue tracking system have a DataContract object called Issue. I also would deal with collections which are defined as: List<Issue>.

     

    Once I get a List<Issue> back from the service, what would be the best way to bind it to a GridView and use all the built in features of the GridView? I don't want to implement my own sort/filter for evey type I create. Is there something built-in to the framework that I can use to do this?

     

    I have a feeling I'm overlooking something really simple here.  

     

    What are my options?

     

    Thanks again,

    Dan

     

     

    Monday, August 25, 2008 10:09 PM