There have already been articles written illustrating how to leverage Dynamic Data within an existing web application, but instead of just outlining the steps required to do so, I’d like to give a little contextual explanation as to why you might want to do that, and what benefits may exist.
If you’re developing data-driven web applications with ASP.NET today then you’re already making use of the rich server-control offerings provided (e.g. GridView, ListView, *DataSource), and can attest to the productivity boosts gained (most of the time). What you lack though, when using the existing server-controls, is any notion of data-centricness. Your UI is completely stupid as regards to your data, and requires complete maintenance/upkeep whenever a change is made to your model, no matter how minute it is.
Imagine I’m using a GridView to provide an inline-editing tabular experience to my users. Within the GridView I configure the columns I want to display (or use AutoGenerateColumns), what each column’s header text is, what each column’s sort expression is, and what the primary key is (i.e. DataKeyNames). In addition, since I’m using the control’s inline-editing functionality I have to determine whether I want to allow certain columns to use the default TextBox rendering or provide a custom edit mode by creating a template. Even if I’m fine using the default edit mode provided by a BoundField, I might need to have some validation, which I won’t get out of the box, so I have to create a template. These decisions go on and on…
If you read through every requirement in the above paragraph, you may be thinking that some of that could easily be deduced from our data model (e.g. primary keys, required fields). I would go so far as to say that all of that, and more, should be easily deduced from our data model, and that is exactly the functionality that Dynamic Data provides. Dynamic Data provides the glue between your data model and your UI, making your UI able to automatically reflect model-level changes.
How does Dynamic Data provide that functionality exactly? Remember in the last article I mentioned that Dynamic Data is merely a set of extensions to ASP.NET, which means you don’t have to learn some completely new API, but rather a handful of new tools that work along with what you already know. From the perspective of adding data-centric functionality to an ASP.NET application, what we need in order to solve the problems outlined above, and what Dynamic Data provides us, can be broken down into three categories:
- Data-smart server controls
- Field templates for re-usable field-level UI
- Higher-level abstraction of our data model
Understanding why those three aspects are necessary and how Dynamic Data leverages them will make the goals of Dynamic Data much clearer. In the next article I’ll explain in detail how those three features can enhance the development of data-driven web applications.
3 Responses to “Dynamic Data: Kickin’ It Old School”
Leave a Reply