Skip to main content
Home Forums Silverlight Programming Programming with .NET - General return datarow from WebMethod
8 replies. Latest Post by bydia2 on August 11, 2009.
(0)
josh100
Member
50 points
86 Posts
05-19-2008 4:01 AM |
hi all, is it possible to return a datarow from a webmethod?
{
the answer for build is - "not all code paths return a value".
thanks.
robhouwe...
Contributor
3174 points
548 Posts
05-19-2008 6:10 AM |
To prevent the compilation error, you should remove the line:if (dr.Read()) If it doesn't contain any values, it will return null, that's okay.
However, when the webservice contains a method which returns a DataReader, adding the service reference in a Silverlight project returns an error. So it doesn't seem to work to return a datareader. Maybe someone else has other thoughts about this?
05-19-2008 6:35 AM |
dr.read do not make compilation error.
when the method return string, it's ok.
TheResult = dr[
can i returned the whole row from database with datarow ?
05-19-2008 10:46 AM |
I believe there is no support for the datarow object in this version of Silverlight (please correct me if I'm wrong)...
You could create a class containing the properties you want to return in your webservice, fill a list of the class and have the webservice return that.
sladapter
All-Star
17441 points
3,172 Posts
05-19-2008 12:23 PM |
There is no support for System.Data namespace in silverlight 2 beta 1. I heard beta 2 will include System.Data namespace.
Yi-Lun L...
25052 points
2,747 Posts
05-21-2008 12:23 AM |
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.
05-21-2008 9:58 AM |
Yi-Lun Luo,
Are you saying even in Beta 2 DataSet is still not supported? We are kind of hoping it will support DataSet so we do not have write our custom DynamicObject to do binding. Why you are saying DataSet "is very difficult to be serialized by xml"? DataSet already has GetXml() function build in. We have been doing DataSet serialize to XML all the time to pass the data in the WebService call. In our current application we even built JavaScript DataSet object to read serialized XML DataSet data we get from AJAX call to bind the data to our Ajax DataGrid and other Ajax controls. Basically DataSet is just a List of Column object to define Data structure and List of Row object for storing Data. Why it is difficult to be serialized? For me DataSet is just Data holder. It does not have to have anything to do with what database we are using.
Actually I have already written our own code to read serialized DataSet XML data to build a DynamicObject List in silverlight and it works great. Seems we need to stick with this.
I know Microsoft now promote using Entity or Object to hold data instead of using DataSet and I know they have advantages and I like it a lot. But one advantage DataSet has over Object is it's Generic feature. I do not have to write so many objects, and some times it is impossible to pre-define a object without knowing all the fields it contains before hand.
05-21-2008 11:53 PM |
When you call DataSet.GetXml, the DataSet is turned into a string. It's no longer a DataSet. I say DataSet is difficult to be serialized by xml because the DataSet object itself is not marked as DataContract. You can't serialize a DataSet object. When you use DataSet.GetXml to return a string in your web service, the generated SOAP proxy class has no knowledge of the meaning of that string. On desktop .NET and .NET Compact Framework, you can use DataSet.ReadXml to construct a new DataSet object, and use it in Windows Forms and ASP.NET data binding scenarios. Windows Forms's data binding model has sophisticated supporting for binding to DataSet, especially for DataGridView. But Silverlight doesn't. IMO there're several reasons:
First, as you probably know, the desktop System.Data.dll assembly is more than 2 Mb. Even if we can cut off most features, it will still introduce a large increment on the size of runtime. As a browser plug-in, we have to keep the Silverlight runtime as small as possible.
Second, the data binding model in Silverlight is a subset of that in WPF, and is significantly different from Windows Forms and ASP.NET. In WPF, when you try to bind to a DataTable, we'll call its IListSource.GetList method to create an IList object, which is actually a DataView. Each member in the DataView is of type DataViewRow, which implements ICustomTypeDescriptor. ICustomTypeDescriptor is used to dynamically construct a type. But this interface is not in Silverlight yet. Even static reflection has limitations in Silverlight due to security concerns. So this model can't work in Silverlight. Also by dynamically constructing a type, performance will drop. See this blog post for more information.
Third, while I can't 100% assure you at this time, it's likely that we'll support ADO.NET Data Service (Astoria) in Beta2. Astoria is a special kind of WCF REST service. It does a good job for data driven applications. It's built on top of Entity Framework, and it'll expose the data as JSON or ATOM, and it's extensible. See this blog post for more information. Also we already support LINQ to XML, so you can easily create an object model from a generic REST service. With so many support for modern architectures, I don't see any values supporting DataSet will add. But anyway, you can continue ask for this feature. If enough people are asking for that, it's likely to be supported in VNext.
bydia2
12 points
7 Posts
08-11-2009 8:12 AM |
I've been pushing for DataSet implementation on other blogs... just found this one.
I agree with sladapter, as to the importance of having a generic DataSet in Silverlight. At least as an optional .dll. All it needs to do is take an xml map it to strong type dynamic class. And after changing data, spit out an dataset diffgram xml. The problem with some of the new data driven applications is that they are not easily scripted, they must be hard coded.It's like I'm being forced to do hardware, when all I want to do is continue writing software.
Our company has an investment in our own framework that uses dataset and our own scriptable workflow engine. We can create new business apps within minutes just by generating workflow scripts.
Our DataSet usage starts with :
DataSet ds=new DataSet(); //the rest is control by our scriptable workflow.
return datarow from WebMethod