I have been watching various videos and playing around with .NET Ria Services for a few months now and thought I would write about what I see as an extremely cool feature that will greatly simplify server side coding and make for an very flexible presentation layer.

I cannot emphasise enough here that this is NOT dragging all the data to the presentation layer and then filtering, it is doing the filtering on the server and it is giving us the freedom to filter however we like.

.NET Ria Services has not been released at the time of writing this article but it won’t be to far off now with the release of Visual Studio 2010 in April on the horizon.

You can read up about RIA Services and get all the required software over here WCF Ria Services Get Started



But now, for the cool stuff (if your a geek).

Let’s take this simple architecture shown below. We have our initial version of the front end, Presentation 1.0 and several months down the track along comes Presentation v2.0 which has more refined data requirements that need to query the backend in a way that has not been catered for. Wouldn’t it be great if we could still do this without the need to modify the backend at all. Even better, wouldn’t it be great to be able to write the backend with no knowledge of how the presentation layer will be querying for data.Arch

Enter .NET Ria Services and the EntityQuery object.

The following steps are required:

  1. Create a Model by creating an ADO.NET Entity Data Model (Rebuild you solution after doing this)
  2. Create the Domain Service by adding a Domain Service Class
  3. Select the Entity you want the Domain Service to manage.

I won’t go in to the full detail of doing this as it is covered on numerous blog posts and videos already, one of which can be found here WCF Ria Services Get Started

Once you have done steps 2 and 3 you end up with the following code structure:

[EnableClientAccess()] publicclass AccountDomainService : LinqToEntitiesDomainService { // TODO: Consider// 1. Adding parameters to this method and constraining returned results, and/or// 2. Adding query methods taking different parameters.public IQueryable GetAccount() { returnthis.ObjectContext.Account.Take(1000); } publicvoid InsertAccount(Account account) { this.ObjectContext.AddToAccount(account); } publicvoid UpdateAccount(Account currentAccount) { if ((currentAccount.EntityState EntityState.Detached)) { this.ObjectContext.AttachAsModified(currentAccount, this.ChangeSet.GetOriginal(currentAccount)); } } publicvoid DeleteAccount(Account account) { if ((account.EntityState EntityState.Detached)) { this.ObjectContext.Attach(account); } this.ObjectContext.DeleteObject(account); } }

You are free to modify this and add whatever you like but lets leave this in it’s simplest form to illustrate the point of this article. (I have added the Take(1000) at the end to reduce the data size returned)

Take note of the GetAccount method which returns an IQueryable object. This will currently return all the accounts in the database and if we run the SQL Profiler whilst executing this method we will get the following T-SQL executed against the database server via the magic of LINQ:

SELECTTOP (1000) [c].[ID] AS [ID], [c].[FirstName] AS [FirstName], [c].[LastName] AS [LastName], [c].[Gender] AS [Gender] FROM [dbo].[Account] AS [c]

Now here comes the magic. All of a sudden the owner of our site, which happens to be a gym, wants to make the gym females only (ok a poor example I know but humour me).

Rather than change our business logic we can change our presentation layer code from this:

AccountDomainContext ctx = new AccountDomainContext(); grdMembers.ItemsSource = ctx.Accounts; ctx.Load(ctx.GetAccountQuery());

To this:

AccountDomainContext ctx = new AccountDomainContext(); grdMembers.ItemsSource = ctx.Accounts; EntityQuery accountQuery = from m in ctx.GetAccountQuery() where m.Gender == "female" select m; ctx.Load(accountQuery);

We have now changed the code so that the query does a filter on gender on the server and returns only the “female” accounts to us and we have made no change to the backend logic at all. I cannot emphasise enough here that this is NOT dragging all the data to the presentation layer and then filtering, it is doing the filtering on the server and it is giving us the freedom to filter however we like.

Here is the T-SQL that is executed on the server to prove this:

SELECT [Limit1].[ID] AS [ID], [Limit1].[FirstName] AS [FirstName], [Limit1].[LastName] AS [LastName], [Limit1].[Gender] AS [Gender] FROM ( SELECTTOP (1000) [c].[ID] AS [ID], [c].[FirstName] AS [FirstName], [c].[LastName] AS [LastName], [c].[Gender] AS [Gender] FROM [dbo].[Account] AS [c] ) AS [Limit1] WHERE N'female' = [Limit1].[Gender]

Simply awesome RIA Services dudes! This will change and simply development of backend logic and database logic immensely and give me the freedom to change how the presentation layer queries for data with ultimate flexibility. 10/10

Video Demonstration

Source Code ZIP

BondiGeek