Why is RIA services known as black magic? - wcf-ria-services

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.

Related

Why should I use OWIN for a service-based API when I can create web-based RESTful endpoints?

I am in the process of rewriting the architecture for an existing application that will be hosted on Azure and have at least two API's - one public, and the other private for internal RESTful-related CRUD calls.
The main technology stack is ODATA, WebAPI2, C#, MVC5, EF, AngularJS. My thoughts were that the RESTful endpoints would all be exposed through the Azure Web Role (just like any other URL).
In reading more about OWIN and using it with the WebAPI and the Azure Worker Role, it seems like exactly the same thing, but as a service.
Is there any advantage to going this OWIN route (where come to think of it, I could even write a WCF service to do the same thing) rather than the web-based RESTful API calls?
I'm looking for some reasons why I should go through the exercise of moving to a service-based API.
Technology speaking
For your public API, I would suggest to do it with Owin in a RESTful way. This will create a facade to your internal systems.
Internally, WCF will offer better performances.
PROS
Maintenance is way easier with a good plan. Because of its decentralized design, the risks due to refactoring are contained in a specific context. Maintenance is all about minimizing and controlling risks related to changes.
Those links are more talking about SOA but I'm sure you can extract the information needed from them:
Services by Contracts
Amazon SOA
Amazon Shareholders Letter
CONS
You should be aware though since it also has drawbacks. You will need solid Unit Test, Logging and Versioning strategies.
Hope this helps a little. I tried to keep only the essentials since a complete answer to this question could be published as a book.

end-to-end RIA-like client/server patterns? non-Entity Framework contexts?

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)

WCF Data Service with Entity Framework - interoperability concerns

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.

LightSwitch vs WCF RIA

I've just found out about Visual Studio LightSwitch, Microsoft's new Silverlight-centric RAD tool.
Does this occupy the same space as WCF RIA Services?
Is WCF RIA effectively dead?
I've been doing some reading, and it seems that LightSwitch actually builds on top of RIA. I saw the following in a review in The Register -
Database connectivity and user
authentication in LightSwitch uses WCF
RIA Services, Microsoft's web service
framework for Silverlight, though
developers are shielded from the
details. This means there is a middle
tier running on Microsoft's IIS web
server.
Lightswitch does not make RIA Services obsolute. They are both valuable but are aimed at different audiences. RIA Services is aimed at professional programmers that want a high degree of control. Lightswitch is aimed at non-professional programmers. You can think of it as a Microsoft Access for building Silverlight applications.
I don't know where you found that quote "LightSwitch is targeted at professional developers and power users looking to create custom LOB applications", but that's NOT what LightSwitch was intended for at all. Power users, yes, professional developers, no.
LightSwitch is targeted at the non-developer, the type of user who creates "departmental" apps, who would perhaps currently use Excel, or Access. Though a number of professional developers (myself included) have recognised that LS is a fantastic tool for us to use as well, we were NOT the target audience at all.
As for RIA services being dead? Not at all! In fact RIA services is one of the main ways of accessing data that LS currently has trouble with (aggregation, projected entities etc). Using RIA services in LightSwitch is VERY easy. We're hoping, with the interest expressed by developers, that things will improve in that direction in future versions.
I agree with Phil, I tend to think of LS as Access.NET, even though it's far more than just that. Think of "forms over data" with all the latest technologies. Silverlight (both in browser & desktop), MEF, Entity Framework, RIA services etc.
Yann

WCF RIA over Net.TCP binding?

I am trying to improve the performance of a Silverlight 4 WCF RIA application. As it's for intranet use only, I figured switching from the default binary HTTP binding to the Net.TCP binding might improve performance a bit.
However, I am having a hard time just getting a simple proof of concept application running. I have:
switched the proof of conecpt app from Cassini to IIS (7)
added the appropriate bindings and enabled protocols on IIS
added a clientaccesspolicy.xml file to my IIS root
Now, when I create a context like so:
var context = new DomainService1(
new Uri(
"net.tcp://localhost:4502/BusinessApplication/BusinessApplication2.Web/ClientBin/BusinessApplication2-Web-DomainService1.svc"));
... I get the following error:
The provided URI scheme 'net.tcp' is invalid; expected 'http'. Parameter name: via
Now I'm stumped. As far as I can tell, the problem is that the client being created by the auto-generated WCF RIA code needs to be told that it's to use a Net.TCP endpoint, but I'm unsure how to do that.
I've found plenty of blog posts explaining how to get WCF services going over Net.TCP, but I haven't found a single one talking about WCF RIA, and I can't find any offical documentation either. All of those explanations involve changes to the web.config file that seem unsuited to a WCF RIA app.
Could some one please either explain to me how to get this configured, or point me at some documentation?
WCF RIA Services depends on HttpContext which is not available with Net.TCP binding.
As for perf issues, could you elaborate a bit further? What is the bottleneck query/operation? What is the size of data (entity size x entity count)? What is the delta between your perf requirements and current perf?
Perhaps there are other ways that don't involve Net.TCP?
Thanks.
Dinesh
(WCF RIA Services Program Manager)