Practical ASP.NET

AJAX Data Strategies in .NET 4

Peter Vogel returns to creating an AJAX-enabled ASP.NET application using the latest tools out of the AJAX library and .NET 4. However, it turns out that you can't there from here... at least, not right away.

• By Peter Vogel
• 04/29/2010

A few months back in an article and a series of columns, I worked through an AJAX-enabled application that needed no server-side code in my ASPX code files. Instead, I used JavaScript in the ASPX file itself and ASMX or WCF Services to do all the database retrievals and updates.

This is the new paradigm for Web applications: The browser retrieves a page that interacts asynchronously with a series of low-bandwidth, dedicated Web services. Only when the user is ready to move to another page does the browser do a traditional postback. The result should be faster, more responsive apps that make fewer demands on both the server and the network.

I'm going to do that project over again, but this time I'll be using tools from the current version of the AJAX library: the dataView, the dataContext and their support for databinding. On the server, I'll be using the .NET 4 versions of WCF and Entity Framework. However, it's worth remembering that the AJAX library isn't tied to .NET 4, so you should be able to use it in existing .NET 3.5 applications. Also, you could always use an ASMX Web service rather than WCF, and Entity Framework isn't critical to this project.

It's an interesting time to do this. Microsoft's client-side strategy is in flux because of the company's new commitment to jQuery. But it's also in stasis because very little investment will be made in the AJAX library (especially in databinding, the script loader and templating) while Microsoft focuses on jQuery. But if you want to do AJAX in .NET right now (or just want to see what the technology looks like) these columns will show what does -- and doesn't -- work.

The JSON problem
To generate the fewest lines of code in my WCF Service, I could try returning Entity Framework objects from a WCF service. While tempting, this approach won't work with the current set of tools -- your EF Entities won't make it down to the client in a way that the dataView or dataContext objects can use them.

The problem is that the dataView and dataContext objects expect to get JSON-serialized objects. And the EF Entities don't serialize into JSON objects. To be specific, if you look in the code file for your EF model, you'll see that the DataContract attribute on each of the Entity classes has its IsReference property set to True. That setting defeats JSON serialization.

There are two ways around this problem: First, don't return EF Entities. As I discussed in an earlier column (Converting from Business Objects to User Interface Objects), it's likely that your Entity objects aren't a good match for your UI, anyway. So, in your service, use the EF objects to retrieve data but create a set of Data Transfer Objects (DTOs) to send to the client. In Visual Studio 2010, if you pick the "AJAX-enabled WCF Service" template when adding a WCF service to your site, Visual Studio will take care of generating all of the WCF configuration entries for you (otherwise, see that jQuery article for how to configure your WCF service).

As long as you don't do anything foolish with the DataContract attribute on your DTOs, everything should work out fine. Or you could use an ASMX Web Service if you're not ready for WCF yet.

Enter WCF Data Services
The other solution is to use WCF Data Services. WCF Data Services have an embedded serializer that can, apparently, convert EF Entities to JSON and back again (it's all part of Microsoft's OData strategy). The only wrinkle is that WCF Data Services are REST-based rather than SOAP-based, so the syntax for getting entities isn't based around calling methods. I discussed RESTful services in ASP.NET 1.1 a few years back. WCF DataServices in .NET 4 is a much simpler process.

So, in my next column I start a project to create an ASP.NET page using the dataView and dataContext objects. It's a full CRUD page with no code in the ASPX code file. While using a standard WCF service and DTOs might be a better design, I'll use WCF Data Services to return EF entities, primarily so you can see how WCF Data Services works. Along the way, I'll be pointing out what does work, while also discussing some items that aren't quite there yet.