RIA Services - Still Not Baked Yet
As regular readers of my blog know (RIA Services Concerns Squashed), I have been a lukewarm supporter of RIA Services for Silverlight. As many of you know, Brad Abrams and company have come through with their latest release (RIA Services Preview July '09) with lots of changes I've been hoping for. Honestly I haven't had time to look at the new build (probably this weekend), but I am hopeful of its overall direction. I am still somewhat tentitive about some of the basic behavior of the framework but I will hold my tongue until I have more time to dive deeper into the code.
What really concerns me is that I've talked to students and others and many are opting to building systems with RIA Services right now. This only concerns me because RIA Services is not part of Silverlight 3 and is not released. Actually, the July version is a "Preview" (something like a CTP) which means they haven't even reached Beta with RIA Services. Now many these developers are working on very long time lines and can wait until RIA Services releases, but while investigating it makes a lot of sense (and I encourage everyone do that), building production code against a framework that is still in transition is a risky venture in my opinion.
I am curious who out there is using RIA Services in production systems that will ship this year. Could you comment on the blog with whether you're using it for an upcoming project?
Based on a work at wildermuth.com.
I am on hold wih .NET RIA Services. It costs to much time to find walkarounds. Finally when a it comes to RTM - it costs again to make all changes. And dont forget- Services are the stable layer of an application. Changes there are the most expensive part.
Shawn,
Stefan,
I've used RIA Services for several projects since the first preview. Seems they're doing a good job on it. As with moving from SL2 to SL3, there are breaking changes in moving from one RIA preview to the next. These aren't show stoppers in either case.
Besides, I am never confident enough to implement operation oriented security when using those RESTful stuff.
Let's say there is a table in database. In some operation context, a certain user is denied to access the data in that table. But in some other operation context, he should be allowed to access some data in that table together with some others from elsewhere. It can be done very easily by using SOAP services becuase SOAP services are strongly operation oriented.
My question is: is that also very easy to do the similar things in REST services?
My feeling is that REST services are very data oriented. Although I am pretty sure it is feasible, but the required effort on setting or coding is obvously bigger than that with SOAP services because , when architecting the system, you need to be more careful to determine data accessibility in various operation context and, when developing the system, you need to continuously look back to audit the security in your code.
When I tried .NET RIA Services including its UserService, I didn't have much better feeling than what I mentioned above. So finally I decided not to use it in development at all in near future.
I think the most useful thing that .NET RIA Services can do is converting Web developers, especially those ASP.NET developers into RIA developers. Web developers are used to finishing their jobs by finishing web front-ends on server side. The biggest issue for them to change to developing RIAs is RIA development normally requires writing more codes to handle the communication between server side and client side. In that case, .NET RIA Services really saves time and is very attractive to them.