Avid readers (if there are any!) may remember my recent post in which I extolled the virtues of the DomainDataSource control, and how it enabled us to use RIA services in ASP.NET sites. Well, having bashed my head against the wall for a week or so trying to get RIA services working with ASP.NET, I have decided that the support for this is actually quite limited, and not enough to make it a viable option.
I mentioned in that blog post that I had been very cynical about the ABCDataSource controls already offered, but had been pleased that this one didn't seem to require anything in the UI layer that shouldn't be there. The problem seems to be that the DomainDataSource is the only way to communicate with the RIA service from code, so you are restricted to using the ABCDataSource controls for all data access.
Now, if you are producing a pretty management demo, then this sort of thing is fine, but in a real application, you often need to do more than can be done with such a control. If you want to display a list of customers, edit one and have the changes send back to the database, then you can do all of this without writing any code. Great stuff. In theory, you can add new customers the same way, although I never managed to get this working. I spent a lot of time reading up on the DetailsView control, but just couldn't get it to work with the DomainDataSource.
However, all of this is fine for noddy applications (no disrespect to Noddy, who was one of my favourite childhood characters), but fails when you hit a more realistic situation. For example, in an e-commerce site, clicking the "Buy" button on a product page may require checking to see if the visitor (who may or may not be logged in) has a shopping basket (cart for any US readers), creating one if not, or associating the visitor with it if there is one, then adding the product to the basket. Checking out would require pulling all the items from the basket, inserting a new sales order and adding each of the basket items as an order line, as well as creating or associating a customer account with the order. You just can't do that with a control on the page! Even if you could, I dread to think what the code would look like.
The only answer to this sort of problem is to write code. Unfortunately, there doesn't seem to be any way to get at the RIA service from code. Actually, that's not strictly true. You can pull data from the service quite easily by creating an instance of the RIA service, then calling a method that returns data. The problem comes when you want to insert, update or delete data. All of the methods created on the service require you to pass in an object that is associated with the data context. You can't just create your own object and pass it in as this won't work.
So the logical step is to get hold of the context and handle it from there (which is actually the right way to deal with RIA services). OK, this one had me going for some time. I eventually gave up and concluded that you can't get the context from code. Maybe it is possible, but I don't have enough years left to try and work out how it's done. Very few people seem to be using RIA services with ASP.NET (which is telling in itself), so there's little help around. The good folk in the RIA services section of the Silverlight forums weren't able to help, as no-one seemed to have used RIA with ASP.NET.
So, that was the end of my foray into RIA services. I guess I'll be back again when (or if) I ever have time to get into Silverlight, as they seem to be the preferred method of data access there. In the meantime, I'm off to explore WCF, which is RIA's big brother, and seems to play ball very well with any code you like.