Project templates just got bigger

One of the new things we are working on in ASP.NET is not directly connected to the new and improved features but rather to how we deliver them. Instead of packing all the functionality into binaries and DLLs, Dynamic Data "implements" a lot of what it provides in project templates. This is a pretty novel concept for ASP.NET with unique challenges yet some very exciting possibilities. Want to know more? Well, read on...

Your everyday basic project template

Most project templates you find in a default installation of Visual Studio (at least under the Web category) are very immature, little things. I do not mean to say they are useless. They certainly have a lot of potential... but you have to nurture them until they can develop into strong, functional applications, web sites, and utilities. Without any encouragement they pretty much do nothing. So I guess they might be a bit useless. Have a look here to the left.

There is nothing more here than a simple web.config file and a blank WebForm. Not even a friendly "Hello world". Instead, when you run this site all you see is a clean, white page. Essentially, this is an altricial creature in the Project kingdom.  Now, if you wanted this baby beast to do something - like... oh, I don't know... display and edit some data - you would have to: add database connections, create data models, drop in controls, specify tables, choose columns, enable flags, hook up events. And you would have to do all this for each table of data you are interested in. Quite a lot of work, if you ask me. And things get even more complicated if you want to add fully-editable and filterable relationships and other goodies.

A beefed up template

So we decided to make things a lot easier. And that is how, quite precocially, ASP.Net Dynamic Data was born. If you want to see how quickly you can get a working site running, see this excellent screencast by David Ebbo.

The idea behind Dynamic Data is to get you up and running with a fully usable app in minutes. To achieve this goal, however, we had to depart from the tradition of providing only the simplest application skeleton.

Observe to your right: this fine specimen is the default Dynamic Data project template that shipped as part of the December 2007 ASP.NET 3.5 Extensions Preview. All of these files (and a few more under the collapsed Images folder) are what you get when you create a new Dynamic Data project. While the exact composition of this template has changed significantly over the last few months (e.g. the folder structure is different, we favor Global.asax instead of web.config, and all the files are code-behind based), this is still a very good example of everything that you get by default:

• web.config
• Default.aspx - except this one actually does stuff
• a number of page templates
• a master page to make sure it all looks the same
• a bunch of user controls
• some styles
• a few images

That is basically the trick - you get half or even more of a fully functional application for free thanks to the Dynamic Data engine and the project templates. And since the functionality is divided between different files, you can easily customize and replace pieces as you see fit.

How do we nurture these templates?

All of this comes at a price, however... at least to us - the Dynamic Data team. One of the reasons why the majority of the default project templates is so small might very well be because it is a lot easier to support them (that and the fact that it is hard to come up with anything more complicated that would make a meaningful default). The smaller the code the less you need to worry about breaking it.

In the case of Dynamic Data the situation is further complicated due to the number of various combinations we want to support:

• C# vs Visual Basic
• Web Sites vs WAPs
• Linq To SQL vs Entity Framework
• Inline vs Code-behind

In order to avoid having... let's see... 1, 2, 3... 16 different project templates and lots of redundancy we have a pretty neat solution that combines templates, token replacement, automatic language translation, file stitching, and a few other steps to produce the end result from the absolute minimum number of source files. And in the rare few cases where our automatic tools are not sufficient to account for the differences between the various technologies we use or support, we just have manually written overrides.

On the positive side, this means that a large part of the functionality is not locked away in some impenetrable, sealed DLL. If you do not like how something works, you can quite easily replace it. And if by some remote chance there is a pretty nasty bug in the Dynamic Data CTP code (which there was), your chances of a workaround are just a bit better.

If you still have not checked Dynamic Data out, give it a go. You might just get done with your next project that much quicker.