My rambling thoughts on exploring the .NET framework and related technologies
Home of the surprisingly popular Pixata Custom Controls For Lightswitch (well, it was a surprise to me!)

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.

This post gives more details of my exploration, discoveries and eventual disappointment at the conclusion.

As I mentioned in my post about the DomainDataSource control (DDS), the same RIA services toolkit that provides the DDS also supplies a validator control called the DomainValidator. As this provides such a useful piece of functionality so easily, I thought it was worth a quick post about it.

Using the DomainValidator control, you can add validation to your ASP.NET pages really quickly and easily, and preserve the n-tier structure of your application - something you coudln't do with the regulat ASP.NET validators.

Unlike its predecessors, the DomainDataSource control is a brilliant feature that you can use with RIA services to have code-free access to your data from the ASP.NET page - without sacrificing the structure of your application.

Previous data controls required data access code in the control, so you ended up with SQL in the presentation layer. Not a good idea. The DomainDataSource control doesn't do this, and is a vauable addition to your ASP.NET/RIA services toolbox.

This post explains what the control is, and shows how to use it.

RIA services are a great way to access your data from ASP.NET pages, but out of the box, they provide limited access to data not directly in the entity object itself. For example, an Action entity object (that holds information about an action that a user must do) will hold the ID of the user who has to do the action, but won''t hold the name of the user.

This post explains how you can extend the objects RIA passes back, without having to create new ones, or jump through hoops to do such a simple requirement. It also shows how to modify the Linq to include the information you want.

Anonymous types are a common occurrence when using Linq queries, as you often return objects that don't correspond exactly to objects in the entity model.

The problem is that these anonymous types can only be used easily in the same code block as the one in which they were created. If you try and pass them into another block, or retrieve them in a data event of an ASP.NET Repeater control, you'll run into problems.

This post shows how to get around this problem quite easily, and how to give yourself strongly-typed entity objects that can be passed around.