In general, are WCF Data Services interoperable or Microsoft specific?
This ADO.NET Blog link shows very nice how EF could be used in WCF Services. But it also shows in that simple example a method with return type: IQueryable<Patient>. Is this breaking the interoperability?
Is there any special treatment regarding these Data Services with EF to be interoperable? Are there tips or things to take care in this matter?
This MSDN overview says WCF Data Services are interoperable. I believe returning IQueryable<> is to support the OData query expressions.
I'd assume you won't have to do anything special (other than maybe exposing the services with WebHttpBinding and WebHttpBehavior).
If you're evaluating technologies you may want to look into ASP.NET MVC4 Web API as an alternative to WCF Data Services. Take a look at this blog and this forum post.
Related
We have a WCF Odata Service enabled. We are planning to migrate to Web API2. I was told we are not going to user Odata.
Could someone enlighten me on, why shouldn't we use Odata. Is it going to obsolete soon. What are the downsides of using it, and can we use it without Entity Framework. Please suggest a good tutorial. Thanks.
This article https://learn.microsoft.com/en-us/aspnet/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/create-an-odata-v4-endpoint was written less than a month ago, so I can't see any reason why you couldn't use Odata in Web API2. Shouldn't is just an opinion and not really what this site is for. I'd recommend asking whoever made the decision for their reasons.
As for a good tutorial, the article I just linked seems like a fairly good place to start.
From the article:
Web API OData does not require EF. Use any data-access layer that can translate database entities into models.
We are currently looking at converting from WCF Data Services to WebApi with Odata. Our entity model is defined using an entity framework defined as an edmx. Im struggling to get the edmx working with WebApi OData due to relationships and complex properties.
I'm just wondering whether someone has successfully implemented webAPI with odata on a bigger sized edmx (that has relationships as well)? Any advice would be great.
You may try using RESTier -- a .Net framework built upon Web API OData. There are several things you may need to pay attention:
RESTier has an EF provider which is quite similar with WCF data services. So it should work wiht the edmx model with little tweak.
RESTier is not a "competitor" for Web API OData, it's built upon Web API OData and can fallback to Web API OData.
RESTier currently is a preview version, but it has good support for the common features used of OData service.
If you tried out and find it cannot work, you can create an issues on https://github.com/odata/restier/issues with more detailed information, if you successfully make it work, it will be great you share your experience.
I like all the features that JayData provides. I am wondering for when I occasionally have a non-O-Data restful service if there is a way to manually hookup CRUD ops to my existing jaydata entity definitions so that I can take advantage of all the kendoui/knockout goodness that comes with this.
Is there any example where a jaydata entity definition is manually hooked up to restful service url kind of like the jquery method?
Thanks
Our webapi provider is what your are after. Do not worry about its name, webapi is a microsoft framework for rest apis, hence the name, but it should work with other restful endpoints, php, java, ruby, etc. Of course it is only good for crud, as filtering, paging, ordering and projection is only standardized in odata. Also, for paging length() is needed, so that must be implemented on the server side, too.
Give it a try and tell us about your experience, good or bad, we're to help you.
Or consider using oData, JayData can act as an odata endpoint on the server side, we also have hosted odata service.
I have posted this same question in the msdn forums, but nothing yet ..
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/60cf36d1-c11a-4d8a-9446-f1d299db1222
I'm working on a project that is an MVC app that will be sourced data via a WCF service that may or may not be getting data via EF, but will definitely be using Stored Procedures..
The MVC app will maintain state in the session, and the entity-tracking portion of this state would preferably function much like the RIA Services DomainContext. Whether or not this context encapsulates saves and changesets is not really all that important, but how entities are loaded into the context and relate to one another (navigation properties) are.
Question 1: Is there such a pattern/solution in existence?
Question 2: Should the MVC and WCF layers share the same DTOs/Entities via a class library? (thereby maintaining state-awareness, navigation properties, etc on both ends of the pipe?)
Question 3: Does using WCF Data Services help solve these problems?
Question 4: Is this all misguided and is there a better approach?
Pretty basic stuff here..
The solution is use a WCF Data Service, and in the client add a Service Reference pointing to it. The client-side proxy will include a proxy and the context classes I was looking for, similar to RIA. If you're accustomed to RIA, there will be some differences and caveats, but by and large it's easy to work through and provides a client-side proxy to your server-side ObjectContext (or whatever repository you expose through the DataService)
Why do people call RIA services a black magic? What kind of black magic do they refer to ? Also, i have seen most people do not use RIA even though they are in Silverlight world. Why is it so? Even on stackoverflow, the % of people asking as well as answering to RIA services question is very very low. Why is it so?
WCF RIA Services provides the following benefits:
Makes a WCF RIA service that supports IQueryable and IEnumerable; WCF RIA Services creates client-side proxy which allows you to send only expression trees over the wire from the client in order to get back just the data you need. For example: you can call a method in your ria service called GetProducts() but also add a LINQ lambda such as GetProducts().Where( d => d.Quantity > 50 ) and only the expression is sent over the wire to the server. The server does the filtering and returns just the matches as strongly typed objects.
Dynamic generation of OData, REST/JSON, and SOAP endpoints with little more than a single line per endpoint in your web.Config.
Ability to automatically flow business rules created at the middle tier into the client tier
Allows you to efficiently flow validations from the middle tier to the user
Allows property, parameter, method, object, collection, and changeset level business rules through simple data annotation validator decoration
There are some deficiencies:
Still does not support WS-* (will in 5) for RPC
OData provider is not queryable
Well, I have not yet heard of people referring to WCF RIA Services as black magic.
I believe there is a small number of people using it (compared to the number of people writing stuff in Silverlight), because it is younger. People may have been developing their Silverlight applications for some time now (version 3.0 came out in July 2009) using classic WCF Services.
WCR RIA Services is still new (version 1.0 came out in May 2010, the final SP1 in December 2010) and we all know the rule, "Never change a running system", so if someone already has a working WCF webservice, why change it? In my case, we experimented with Silverlight and WCF some time ago and decided to wait. When RIA Services came out we thought that was great and started working on a Silverlight version of our main application. It is much easier using RIA Services in a new project than chaning your webservice access in an existing one.
In addition to that it should be noted that Silverlight is not limited to business applications with database access using a webservice. Therefore there may be quite a few Silverlight developers who do not need any kind of webservice.
Another reason might be the fact that for web applications requiring a database other technologies like ASP.NET, ASP.NET MVC, even PHP or JSP (and possibly others I may not even have heard of) have existed for quite a while. And although business applications ought to look nice, too, it usually is not the top requirement to have all kinds of fancy graphics and animations, etc.
Finally, why are so few questions regarding RIA Services asked on SO? Well, they do have their own forum which seems to be quite active. (I use it as a resource when looking for answers but don't post there.)
Regarding the "black magic" part of your question, I believe it is the ongoing shift to convention over configuration. Compared to vanilla WCF, you end up writing very little code to build the client-server relationship. Also, the WCF RIA tooling does a substantial amount of code generation to achieve this.
More on convention over configuration on specifically with WCF RIA and generally at Wikipedia.