Hello, your service method is returning a DataReader. DataReader can't be serialized by xml at all. So there's no way to return a DataReader in a service method. For DataRow, I really don't see it'll add any value in your scenario. You're
creating a SQL query by using DataReader directly. You can easily create a custom object to represent the data object. There's no need to wrap it into a DataRow. Silverlight is unlikely to support the DataSet model (at least not in version 2). The DataSet
model is good for working with complex relational databases in traditional two or three tiers applications and server centric web applications. But it's very difficult to be serialized by xml, so it's not suitable for modern SOA scenarios or client centric
web applications. For future development, on the data accessing layer, I suggest you to use LINQ to SQL (if you're targeting SQL Server), or ADO.NET Entity Framework (if you're targeting other databases). Those technologies are built for modern architectures,
and they'll map the relational database model to an object oriented programming model.
shanaolanxing - I'll transfer to the Windows Azure team, and will have limited time to participate in the Silverlight forum. Apologize if I don't answer your questions in time.
Yi-Lun Luo -...
All-Star
25149 Points
2759 Posts
Microsoft
Re: return datarow from WebMethod
May 21, 2008 04:23 AM | LINK
Hello, your service method is returning a DataReader. DataReader can't be serialized by xml at all. So there's no way to return a DataReader in a service method. For DataRow, I really don't see it'll add any value in your scenario. You're creating a SQL query by using DataReader directly. You can easily create a custom object to represent the data object. There's no need to wrap it into a DataRow. Silverlight is unlikely to support the DataSet model (at least not in version 2). The DataSet model is good for working with complex relational databases in traditional two or three tiers applications and server centric web applications. But it's very difficult to be serialized by xml, so it's not suitable for modern SOA scenarios or client centric web applications. For future development, on the data accessing layer, I suggest you to use LINQ to SQL (if you're targeting SQL Server), or ADO.NET Entity Framework (if you're targeting other databases). Those technologies are built for modern architectures, and they'll map the relational database model to an object oriented programming model.