Is building apps with Dynamic Data faster?

According to users comments in my recent posting “What do you think of Dynamic Data?”, they are under the impression that it is faster developing a web application when using ASP.NET Dynamic Data than with traditional web form development.

Is it really faster? Now remember that I’m a Dynamic Data advocate, so you’d think I’d say “yes”. My answer is “Once you learn the technology and have built several pieces, it is. But before that, it will take just as much work as traditional web form development.”

Dynamic Data offloads a bunch of work to the business logic classes and its control generator. You will spend time developing those business logic classes, adding attributes from the System.ComponentModel.DataAnnotations namespace and validation code. The control generator uses Field Templates to describe the user interface of an individual data type. You will spend time preparing your library of Field Templates. Believe it or not, you have to do the same work if you built traditional web forms, only your business logic is worked into the web form’s code and Field Templates are replaced by dropping controls onto the page.

The speed comes from:

• Reusing business logic classes in different forms; also reusing them in other situations like web services
• A change to the business logic is automatically adapted by your web forms
• A change to a Field Template impacts all consumers of it
• If you use the “automatic scaffolding” feature, the control generator can tell the GridView or DetailsView the exact list of data fields to show. You can change the business logic very easily to show a new field or hide an existing one.

The perception that developing DD apps is faster comes from:

• The ease of generating Entity classes in LINQ to SQL or Entity Framework because of their code generator
• Dynamic Data only needs one line of code to interpret those Entity classes (call the MetaModel.RegisterContext() method in Application_Start).
• Working with the tutorials, you have not gone through the effort of building real world business logic. Your Entity classes are incomplete. Still Dynamic Data gives a pretty good first impression.
• Page Templates are used in the standard example application. Page Templates predefine web forms for each CRUD action, and use the business logic, Url Routing, and automatic scaffolding to create an application that explores your tables. Page Templates may be a model for further page development, but you will often replace them with pages that have the exact features you need. With the introduction of “Entity Templates” (and my own Pattern Templates in DES Dynamic Data), some of that process has been simplified.
• The tutorials and standard example application use LinqDataSource and EntityDataSource. Neither provides a full separation of concerns where CRUD business logic is relocated to a Data Access Object. So you end up writing queries directly in the web forms instead of the Data Access Objects. Also, because the samples are built around Page Templates, Page Templates do not use any special query. Your real world apps will need additional queries. When using Data Access Objects, use the DomainDataSource or my EntityDAODataSource.

I am not trying to put down Dynamic Data here. I hope to establish reasonable expectations for a great tool. Its greatness comes from allowing you to separate concerns between business logic and UI, for which it creates elements of the UI from that business logic. It's a natural pattern for UI development that Microsoft has finally addressed.