ASP.NET Dynamic Data has gotten a bad reputation for being nothing more than a new web application type that allows you to point at a database and get a fully generated site, complete with pages for working with the data in your database (CRUD operations). While that perception does hold some water, it is far from being the complete truth.
Then what is Dynamic Data? Well if you ask me…it is simply a set of extensions to ASP.NET that make developing data-centric applications easier. By “data”, I don’t mean database, I mean data of any kind. When those extensions are combined, they can provide you the scaffolding functionality mentioned above, but that is merely a side-effect of the entire suite of tools.
Viewing Dynamic Data as an application type doesn’t really make sense either as it is merely a complement to an existing web application. In its current v1 incarnation it can supplement WebForms, but work is already underway to bring data-centric functionality to ASP.NET MVC. Sure, there are project templates in Visual Studio for Dynamic Data, but instead of viewing them as a custom application type, look at it as a shortcut for a WebForms application that already has the entire Dynamic Data suite of extensions applied to it.
There are three points that I think are key to appreciating Dynamic Data’s applicability:
- It can be used within an existing web application
- It can work against any type of data, not just relational
- Its metadata can come from anywhere, not just attributes on your data model
Once you’ve seen the above three points come to fruition, then you can begin to see Dynamic Data’s true colors. If then, you’re still not into it, then great, hate it for the right reason.
I’m going to put together a couple articles outlining the above three points in detail, as well as some screencasts that will show off some pretty interesting scenarios/implementations for leveraging Dynamic Data.
One final point that is important to notice is that the set of attributes that Dynamic Data leverages are not within the System.Web.DynamicData namespace, but rather the System.ComponentModel.DataAnnotations namespace. Why does that matter? Because it exemplifies the fact that those attributes are a common set of annotations for any type of data-driven application, with Dynamic Data being the first consumer. Who knows what kind of cool implementations will follow…
