I have a method in my web service which returns a DataView,
I have setup a proxy which talks to this service but when i make this method in the proxy
public DataView GetSales(DateTime SalesDate)
{
ServiceClient client = new ServiceClient();
return client.GetSalesForDay(SalesDate);
}
I get the error "Cannot implicitly convert type 'object[]' to 'System.Data.DataView', i have tried googling this but not getting anywhere, any help would be much appreciated.
Thanks
You can't do this - you cannot and should not return something like a DataView from a WCF service ever. A WCF service would only ever return data - not objects with behavior (DataView contains a lot of behavior - sorting, filtering, etc.).
Instead, in your service code, do this:
query your database with a SqlDataReader
parse out the relevant info you really need (only those fields you're really interested in) into DTO's (Data Transfer Objects) - basically just plain objects holding nothing but the properties of a "sale" that are important to you
return a List from your WCF service
Instead of doing steps 1 and 2 yourself, you could also use Linq-to-SQL, NHibernate, or any other capable ORM to handle that conversion from row/columns in the database to an object for you.
Related
I have a WCF service in which I have a method which returns an IQueryable of an object representing a database table (Accommodation) using Entity Framework. When I try and use that method on the client side the method does not return IQueryable but object. I looked at the code for the service and the Accommodation class that Entity Framework generates has this attribute
[DataContractAttribute(IsReference=true)]
So, AFAIK the client should be able to see that class. What is going wrong here?
Thanks,
Sachin
The type will only appear in the metadata if it is used on the contract. The metadata has no idea what IQueryable is - its a definition of behavior whereas the contract only defines state so the generated code will use somethingit does understand in this situation - i.e. object
It is really not a good idea to use the EF generated types on your service contract - you, in effect, tightly couple your service consumers to your data access layer. Use EF internally in the service and use types which define the data you want to pass around on the service boundary
I'm having very strange issue with my WCF Service Proxy client generated by "svcutil.exe" . My WCF Service works very fine if I don't have a function that returns DataTable. As soon as I add a method that returns a DataTable the client generated by svcutil.exe is behaving very strangely. The Interface is no longer found and client is not able to call the service. But if I add as a Service Reference its working very smoothly. I know its not a good habit to use DataTable as a return type but I need to. I cannot use the Service Reference :-( Any idea why its behaving or what I'm missing!!!
Have a look at the DataTableSurrogate class. It is used by the SyncFramework for serialization and really easy to use.
MSDN DataTableSurrogate
You shouldn't really serialize datasets, instead you should use datamodels and keep anything to do with datasets, tables, readers etc on your backend & in the business layer.
But.. if you want to do so you need to add the following "include" in svcutil, which is causing your issue. (Tells to reuse the types defined in System.Data.dll and not generate them in the proxy)
/r:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
I have an object of the form:
public class Report
{
m_filter1;
m_filter2;
...
m_filtern;
AddFilter1(int a)
{
m_filter1 = /* some logic of filtering results using the value of a */
}
...
}
Also, a corresponding static method used to utilize the Report class:
public static List<Result> GetResults(Report r)
{
/* use r to query the DB and return an array of results */
}
As this method needs to be exposed using WCF, i must also make the class Report available for 'outside' (client) use, but its member-methods, which hide the internal plumbings, cannot be used in the WCF proxy class generated for it.
As i can't expose the private members of Report, how can i elegantly solve the problem of member-methods needed on the consuming side?
I thought of a service contract of the form:
public class ReportingService
{
Report m_report = new Report();
AddFilter1(int a)
{
m_report.AddFilter1(a);
}
...
}
i.e., to wrap the member-methods of the Report class using a single Report instance - but that puts a limitation of using a single, non thread-safe object shared by all the calls to the service.
Is there anything basic i'm missing here? i'm quite new to WCF, so i've probably overlooked an easy pattern of solving this out.
Thanks,
Harel
Well, as you've noticed - WCF only ever conveys data across the server-client link - and that's absolutely intentional. WCF handles serialized messages - data only. Think about it for a second: WCF is totally interoperable - your client could be a PHP site calling you - how would those guys be able to execute your .NET code??
So basically the design recommendation is: make sure your data contracts are just that - pure data, no behaviors, no methods, nothing like that.
If you need to do something on a piece of data - define a service method for it! That's what the whole service-oriented architecture is all about.
So basically: there's really no elegant or proper way to achieve what you want - except for making your methods into service methods that operate on simple data contracts.
I have seen blogs and people saying Returning dataset/datatable from an ajax enabled wcf service is a bad idea.... I have gone through this Scott Hanselman's blog about datasets fr0m wcf...
So what is the alternative for dataset returned form ajax enabled wcf service?
Well, basically, on your server side (where your service method is implemented), either use straight ADO.NET SqlDataReader and assemble the data retrieved into custom classes, or use an ORM like Linq-to-SQL or the Entity Framework or NHibernate or ... or... or..... to do this job.
Then, when you need to return data, either return a List<MyClass> or some other structure, which gets serialized into JSON or XML and doesn't carry the overhead of a whole DataSet/DataTAble.
I got a class called "Board" and one of its property's is an ObservableCollection. When i send the ObservableCollection through WCF (from server to client) end call it from my proxy, it's turned into an Array, which is no good for me.
Can i keep the ObservableCollection after being sent, or do i have to kick the Array till it becomes an ObservableCollection again?
Check out the 'Configure Service Reference' option in the context menu in VS for the reference. You can choose the collection type that is transmitted across the service. By default I think it is set to array but there are several choices (I believe list and observablecollection are options).
EDIT: I just checked, and unfortunately observable collection is not one of the choices. It looks like you'll have to pick from:
Array
ArrayList
LinkedList
List
Collection
BindingList
By default - no, you cannot do anything about it. WCF will serialize your structures into something that can be represented with XML schema. XML Schema has no knowledge of anything but raw, and fairly simplistic data structures. You can only transfer concrete, raw data - no "magic" behavioral addon.
There is one solution to the problem, IF you own both ends of the wire: you could put your service and data contracts into a separate class library assembly, and share those between server and client. In that case, you only ever have one single implementation of your data contract - your ObservableCollection.
If you share that assembly between your service (implementation) class, and the client (add the reference to that assembly before you "Add Service Reference" from Visual Studio!), then your client should pick up that ObservableCollection and continue to use that (instead of creating a XML schema compatible Array on the client side).
Thank you both for the answer.
I will look at both solutions when i continue the project, and will start with try and change the Collection send through the wcf service.
I'll let you know what works for me...