Tagged with ADO.NET Data Services
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.
While Niagara is not going to require that you specify your validation attributes using its DSL, there are some benefits I think we can get by loosely coupling the validation. To that end, i've come up with a very first draft of the DSL to define the attributes. I've decided that instead of being very English-like, to mimic the "M" style of language. Here is my take:
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.
I am happy to see that the Data Programming group at Microsoft have been hard at work as usual. They've just released their PHP toolkit for ADO.NET Data Services.
I've been running Windows 7 as my primary machine now for a couple of months (first the Beta and now the RC). I love the OS but there have been a couple of frameworks that didn't work right. The one that perplexes me the most is ADO.NET Data Services 1.5 CTP1.
I had a great time at the SQL Saturday in Atlanta today. I did two talks: Using MSchema and ADO.NET Data Services for DBAs. If you were there, thanks for attending. If you wanted to grab the code and slides, follow the link above!
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.
Mike Flasko just posted that the first CTP is now available for the new ADO.NET Data Service 1.5. If you don't remember what the changes are, take a look at my recent post here:
Mike Flasko announced today the availablility of ADO.NET Data Service v1.5 coming up soon. While this isn't ready yet the new features they are supporting do seem exciting:
I just saw that John Papa's excellent book ( Data-Driven Services with Silverlight 2) is now available for an impressive 40% off. If you are doing Silverlight, I recommend you get this book. I tech-reviewed the book for John and think he's got a winner on his hands. It covers how to do server communication of all sorts with Silverlight. The Promo Code DD224 for 40% off the cover price. Offer expires 2/19/09. It is good for the print or the e-book version of the book.
If you missed me in Bulgaria's DevReach conference, the video of my Silverlight Data Access talk is now available. The original talk's description was:
In this session, we will explore the different methods for dealing with data in your Silverlight 2 applications including LINQ, ASMX, WCF, REST, Astoria and WebClient calls. The session covers both how to consume data as well as how to expose data to Silverlight 2.
This all started with an innocent question by Bob Archer on Twitter. Bob wondered whether he could use ADO.NET Data Services in an application that was being touted as "Software as a Service" (SaaS). His concern was the apparent hard wiring of the Data Source in the DataService definition. This design might assume that you had to connect to a single database for all requests.
In his case, the Entity Framework metadata was the same but the connection string might choose a different physical server and database name. I thought that it shouldn't be too difficult. My first attempt to help him was to suggest interceptors for every entity type and manually change the database string based on some data in the request. This felt hacky so I asked Pablo Castro (at Microsoft) for some advice on the problem. He of course had the solution.
The solution was to override the protected CreateDataSource method on the Service. This method is called during each request to create the Data Source. This happens in the pipeline after the request information has been parsed so you can use request parameters to decide what Data Source to create. You still need to return a Data Source that is the same type as the generic parameter but this means you can determine how to create the object. For example:
I just found out that my changes to the article and code for Silverlight 2 RTW are now live. The article makes the small change that it no longer requires you to use EdmGem to build your proxy (using the Service Reference instead). I've also updated the code example to be compatible with .NET 3.5 SP1 and Silverlight 2.
In case you're not familiar with this MSDN Magazine article, it covers how to implement data access using ADO.NET Data Services and Silverlight 2 including reading and writing data. Let me know if you have questions about it.
I've finally had a chance to update my Silverlight 2-ADO.NET Data Services example. In this new sample I show how to create a Line-of-Business application (an XBox Game editor) using ADO.NET Data Services against both an Entity Framework model and NHibernate. Unlike earlier examples, this one includes implementation against the ADO.NET Data Service Silverlight 2 library to support saving of changed entities. In addition, I show some techniques for paging, retrieving simple types over an ADO.NET Data Service and full styling of the application. I hope to add support for Forms Authentication in the coming weeks.
Feel free to post replies with questions about the sample.
If you are thinking about using SQL Data Services (the data part of the Azure stack) in your Silverlight 2 project, think again. As you might know, ADO.NET Data Services (Astoria) will not work cross-domain regardless of a security policy file (because of some limitations in the two networking stacks that Silverlight 2 uses). Its a problem but in most use-cases ADO.NET Data Services (Astoria) is used on the same domain so no biggie...but...
The Azure SQL Data Service uses Astoria to expose their data to the client...that means that with the ADO.NET Client Library that you can't access SQL Data Services. The reality is that since SQL Data Services requires basic authentication, it would not be terribly secure to call it in any case but this seals the deal.
After some discussion, Mike Flasko (Program Manager, ADO.NET Data Services) has clarified the relationship between the Silverlight 2 Beta 2 Data Services Library and the SP1 of VS2008/.NET 3.5. Specifically he says:
While the Silverlight Beta 2 data services library may work in some scenarios against a .NET Framework 3.5 SP1 RTM server, you should NOT count on the two being fully compatible with each other.
As part of my work on the ADO.NET Data Services support for NHibernate.LINQ I decided that we should support IExpandProvider as well.
Now that my ADO.NET Data Services support has been merged into the trunk of NHibernate.LINQ, I do have some caveats about using NHibernate.LINQ with ADO.NET Data Services. ADO.NET Data Services is a beta 1 product so there are some bugs and issues that you will either need to avoid or work around.
The biggest issue is around entity identity. ADO.NET Data Services must know how identity is established for objects in order to support the Data Service. It does this in a two step process:
After spending time creating my own caches of reflection data I found the NHibernate type information to be more complete and faster. Go figure. At this point I am using the SessionFactory's GetClassMetadata and GetCollectionMetadata to return IClassMetadata and ICollectionMetadata interfaces. So far this has given me every piece of runtime information I need and means that I don't need to do any nasty (and potentially fragile) walking through the property interface of the context object. Whew...
So to refactor my GetResource and CreateResource calls. GetResource is easy. GetResource passes in the query and the full type name (though the full type name may be missing in some cases). The query it passes it must resolve to a single result. That means I can simply execute the the query and if it returns more or less than one result, return an error. Once I have the result I can just check it against the full type name (if it was passed in) and return the value.
I have been diving pretty deep into ADO.NET Data Services (see an upcoming article about ADO.NET Data Services and Silverlight 2 coming soon). I've been looking at the story around non-Entity Framework models through a Data Service and thought that NHibernate through a Data Service would be a great example.
So I tried to get it to work with the NHibernate LINQ project. The example model that the project uses is a simple Northwind model. I thought I'd just take that model and expose it via ADO.NET Data Services. I crufted up a simple Data Context object for ADO.NET Data Model but it didn't work. ADO.NET Data Services was complaining about the fact that the end-points (e.g. IQueryable<Customer>) was pointing at an Entity. This was a bug...a but in ADO.NET Data Services. I hacked together a fix to get around it (and reporting it). If you're interest, the problem is that if the key of the entity is in a base class and *not* named "ID", it fails to find it. Again, this is a bug not a feature of ADO.NET Data Services.
Now that it was working, now what? I wanted to be able to make changes to the model but the NHibernate context doesn't support the updating interface: IUpdatable. (Though I sure wish they'd rename it IUpdateProvider to match the IExpandProvider interface). If you're not familiar with this requirement, note that only the Entity Framework currently support the IUpdatable interface (and is in fact implemented inside of ADO.NET Data Services not directly in Entity Framework). This means that DataSets and LINQ to SQL do not support it either.