Practical ASP.NET

Looking (Suspiciously) at SP1

What's in SP1 for ASP.NET developers? At least one bug fix, a couple of enhancements and -- perhaps -- something that will change your life. But Peter is suspicious.

• By Peter Vogel
• 10/08/2008

Well, the service pack came out on Aug. 11, and the bug is fixed.

So what else is in the service pack that's relevant to ASP.NET developers? As usual with .NET, not much and quite a lot.

The "not much" comes from the fundamental reason that you use a framework: Much of what you use as a Web developer is shared among all developers. The result is that many things that you'll find useful are part of enhancements to .NET generally. For instance, I wouldn't discuss LINQ in this column -- even though lots of ASP.NET developers use it -- because LINQ isn't "ASP.NET-specific" enough.

URL routing is also cool. Back in an older article on implementing REST in ASP.NET ("Building RESTful ASP.NET Apps") I discussed how you could intercept a URL, decode it and generate a matching page without actually retrieving an .ASPX file from the disk. URL routing simplifies this process so you can provide URLs to your users that make sense (e.g., //www.mysite.com/Products/List/Inventory) and are independent of the actual file paths for your .ASPX files. I'll look at this in a later column -- much later, as I describe below.

The Elephant in the Room
The big news for ASP.NET developers in SP1 is Dynamic Data (covered by Roger Jennings in his article "Generate Web Sites Automatically"), which is supposed to go one step beyond DataSources and DataViews: Just tell your application about your data model and you'll get the pages you want. Naturally, I'm suspicious, for two reasons.

First, previous attempts to develop the user interface from the data model have been crashing failures. In application development, a data model "has a relationship" to an object model, which "has a relationship" with your application's user interface. But those relationships are very weak and for good reason. The primary reason for most developers is that if you're after reusability, the last thing you want is a data model that's tied to some specific application's UI.

The primary reason that I don't trust having a UI tied to the data model is that an application's UI is driven by workflow and the organic relationship of people to each other, more so than another part of the application. There's no equivalent, in UI design, to the kind of rigor that Codd's normalization rules provide in database design. In my mind, an attempt to derive the UI from the data model is, at best, a niche solution that will work in only a few cases.

But that's where the Entity Framework (EF) steps in. Acting as the Object to Relational Mapping layer between the data model and your UI, the EF is supposed to provide a way to generate an object layer that converts the data model into something more useful. The question is whether you can build an effective UI on top of EF without having to either create separate business layer objects or write a lot of presentation layer code.

My second reason for suspicion is more prosaic: Will the tool let me do everything I want/need to do? I had the same concerns with the DataView/DataSource model that came with ASP.NET 3.5 but -- so far -- I'm a convert. The event model and the options to insert/incorporate custom code have let me do what Microsoft always promises: Let us take care of the boring, tedious grunt work while you concentrate on writing the code that's unique to your company and delivers real value.

However, just because DataViews and DataSources worked out, doesn't mean that EF and Dyanmic Data will.

So I'm going to start working through living with and creating applications using dynamic data. I don't know the answer in advance, so stay tuned -- or send in your own experiences.