RIA Services: intro, references & something you might not yet know
First of all, welcome to a completely new blog-look! 🙂
The last few weeks, I’ve been playing around with RIA Services (for Silverlight 3), which “simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. The RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.” (uhm, yeah, I borrowed that part from Brad Abrams ;-)).
To clarify this a bit: we’re all used to writing service-oriented SL-apps. Typically, you’d have a webservice or WCF-service residing somewhere, and you’d use the “Add Service Reference”-option in Visual Studio or a WebClient to get your data. I actually like that approach, but it’s a fact that most people are used to working in a typical n-tier environment (just check the numerous posts on the Silverlight .NET forums asking about how to convert an existing n-tier app to a Silverlight app, or about strategies to get data into a Silverlight-app).
Well, RIA Services bridge this gap; you’re still working service-oriented, but it looks and feels different – it feels more as if you were programming in a typical n-tier architecture. On top of that, it offers easy validation & authentication, and useful client-side controls like the DomainDataSource with built-in sorting, filtering, … capabilities. And I’m actually starting to like this as well 🙂
How do you get started with all this? You’ll need Visual Studio 2008 SP1, Silverlight 3 & the last drop (at the moment of writing, this is the May drop) of the services. All downloads can be found at Silverlight .NET, as well as a few good tutorials. For an in-depth view, I’d suggest having a look at the released documentation, which can be found on MSDN’s download page. It’s pretty big (about 116 pages), but it covers a lot of what RIA Services have to offer. You can also find official sample applications here. Don’t want to read through all the documentation? Well, I found Martin Mihaylov’s tutorials at SilverlightShow.NET very useful, you might want to check ’em out!
Or… you might want to come back to this site every few days 🙂 In the next few days, I’m going to start adding posts about these RIA Services and what you can do with ’em – such as paging, sorting, validation, authentication & authorization, how to submit changes or even changesets, … These will come in simple & to the point “How do I …?”-format, for easy reference afterwards (for myself, and hopefully for you as well ;-)). So stay tuned!
So what about that “something you might not yet know” I mentioned in the title? Well, from the moment you start working with RIA Services, you’ll notice that it automatically generates Load-methods on the client for the Get-methods you have on your server. Eg: if you’ve got a GetCustomer-method on your server (which returns an IQueryable<Customer>), a LoadCustomer-method will automatically be generated on your client. But what if you don’t like that prefix? I kind of like my methods to have the same name across different layers (tends to avoid confusion). Good thing is, RIA Services is very customizable in the way it generates code – typically by decorating your code with a few attributes, you can control the code that’s generated client-side. To make sure the client-side method will have the same name as your server-side method, use the following attribute:
1: [Query(PreserveName = true)]
2: public IQueryable<Customer> GetCustomer()
3: {
4: return this.Context.Customer.OrderBy(c => c.CompanyName);
5: }
From now on, GetCustomer will still be called GetCustomer on your client. Nice & easy 🙂
