Tagged with RIA Service
A few months I wrote a series of articles on using RIA Services in a structured MVVM application. The article series was more of a thinking-out-loud exercise than a tutorial, but it makes and interesting read. Here are the four parts:
I've said much about my opinion of Silverlight data access. Currently this is Web Services, WCF Data Services and WCF RIA Services. Let's talk about Data Services and RIA Services and how they are related:
WCF Data Services
Data Services are a good story in Silverlight, but only as of version 2.0 of the protocol. For those users of version 1.0, using Data Services was painful as automatic tracking did not exist yet. Data Services can create not only the data contract classes, but a context object that will do tracking and batching for you. The basic story of how Data Services works is that it takes a context object from a LINQ provider and exposes all the IQueryable endpoints as REST resources that can be queried. This works well in creating a place to execute queries and post/put/delete changes. While Data Services' URI API is another skill that could be learned, the Silverlight (and .NET) client library allows you to just issue LINQ queries to the data service. In addition, the ability to create client-designed graphs (e.g. embed relationships for eager loading) and navigate relationships to the server presents a good API for a data-centric application today.
Welcome the part 4 of my three-part series on architecting with RIA Services. In the last part of the series, I thought I was done with the example and some of my readers challenged me to help them understand how to handle Add/Delete scenarios. Since I was at it, I figured I should show paging and IsDirty scenarios as well, I decided to make a part four.
If you've been following this blog, you know that earlier this week I released the first part of the series oon how to architect your Silverlight 4 projects. In this second part, I want to show you how the Managed Extensibility Framework (MEF) can aid in that process.
Recently I blogged about Brad Abrams' PDC RIA Services Talk and complained about the data source functionality. While the drag-n-drop ability in RIA Services is interesting, I believe that it may be a bad approach for all but the smallest of projects (or one-off projects). In that comments of that article, I promised to show you how I would architect a Silverlight solution with RIA Services.
I've been looking at RIA Services for a long time now. I had the lucky pleasure of being given early access to the bits for what was then called "Alexandria". As most readers of this blog have read, I have had some issues with how RIA Services works. In the mean time Brad Abrams and the team have certainly responded and have made changes to the way that RIA Services works and much of it is for the better. I can see pretty simply how you can use RIA Services to build applications that are really architected well, with true separation of concerns. But there is blood in the water.
I recently had a chance to look at Brad Abrams' PDC video on Building Amazing Applications with RIA Services and Silverlight 4 (CL21). I am perplexed by some of the decisions on the usage patterns of RIA Services implied by the video. I know that there were other RIA Services talks, but since this was by the head of the team, I think this will be used as the exemplar of what developers should write. And that's unfortunate.
If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
Let's dive deeper into explaining these differences and why that might matter.
The goal of Project Niagara is to democratize the validation support. The project wants to help developers add validation support to ADO.NET Data Services as well as Web Services in Silverlight. In addition, it has the goal of allowing multiple ways to supply the validation metadata to the different data access strategies. As it is my opinion that there are scenarios where attributes are not the best idea.
The deliverables for this project will include:
As RIA Services is plodding towards a release, many people are looking at it to help them with validation of data in Silverlight. Using this validation in Silverlight 3 is pretty straightforward but there are some caveats. I want to show you under the covers so you understand what is happening. In this first part of the series, let's look at what it means to use validation from the outside.
Back when Dynamic Data was being developed, a set of attributes was created to help tell the Dynamic Data folks about validation and other metadata so they could create smart scaffolds. These include:
In addition, there were attributes that could tell Dynamic Data about how to name fields and such. This meant that if you were using a POCO class or a DTO, that you could do the annotation like so:
If you've never had the chance to visit my sister site (http://www.silverlightdata.com), now's a good time. I've updated my examples there to include my MVVM, Prism and Declarative UI examples (to go with the skinning/switchable Astoria example). Take a look if you're doing Silverlight data-based applications.
It all depends...
I've finally had a chance to take a look at the July CTP of RIA Services. My opinion is mixed, but its still pretty early. I ran through the simple walkthrough and it was easy to set up but it still felt as if there is too much Visual Studio magic (a complaint I've had for a long time now).
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?
Looks like RIA Services finally has a roadmap. Wahoo:
Here at MIX09, the world got its first view of what Microsoft calls RIA Services. RIA Services is an n-tier solution that supports a variety of scenarios, but in my opinion may be especially important to Silverlight applications.