Preface

Most of the web applications that exist today work with data. From a simple guest book page on a personal website, to a large product catalog of an online retailer, to customer relationship management (CRM) and enterprise resource planning (ERP) systems—applications help people work with data. Working with data means dealing with CRUD. Every database application must allow users to Create, Read (or Retrieve), Update, and Delete records. A product catalog will not be functional unless users can add new products to the catalog, search for and retrieve existing products, update product information, and delete discontinued products from the catalog. Of course, a product catalog rarely exists by itself; it is usually a part of a larger e-commerce system, which has to support all CRUD operations not only for products, but also for customers, suppliers, shipping companies, orders, and more.

Implementing each type of CRUD operation requires some form of presentation, business, and data access logic. Implementing them in your applications usually requires a lot of repetition. Data access logic for products is similar to data access logic for customers, as well as suppliers and shipping companies. You write SQL or .NET code (or both) to insert, select, update, and delete database records. Presentation logic for products is also similar to presentation logic for customers, suppliers, and shipping companies. You create ASP.NET pages with text boxes, drop-down lists, validation controls, links, and buttons. What truly distinguishes the different types of entities is their purpose—the business logic they represent. The Product entity has attributes such as description, price, picture, and rules that define how to validate product names, what to do when a new product is added to the catalog, or when an existing product is discontinued. The Customer entity has different attributes—first name, last name, credit card numbers—and rules that define what to do when a customer changes his billing address or requests to close his account.

Understanding the business logic, a developer can usually figure out how to implement the required data access and presentation logic. The resulting application might not look very pretty, but it will perform its business function. The ASP.NET framework provided all building blocks required for implementing database applications, and although it made web developers a lot more productive, it offered little assistance with the repetitive coding of CRUD operations and made it easy for them to fall into the trap of code reuse by copy and paste. It is unfortunate that a typical ASP.NET application has numerous web pages full of validators and code-behind files where data access code is intermixed with business logic.

There are many techniques for reducing code duplication. In ASP.NET, user controls are an excellent way to extract common presentation logic and reuse it in multiple pages. Patterns, such as Domain Model and Active Record (Fowler, 2002), can be used to encapsulate business and data access logic in application code. Some developers also choose to use stored procedures and implement this logic in database code instead. Separation of the business and data access code from the presentation code allows you to reuse it in multiple web pages without duplication. However, implementing business and data access layers requires more forethought, expertise, and commitment from developers. To be effective, these techniques must be introduced in the application architecture early. Retrofitting them to an existing application requires a lot of refactoring (Fowler, et al., 1999) and can be very costly. It is not unusual for such a refactoring effort to be longer than the initial application implementation itself.

For .NET developers, introduction of LINQ in version 3.5 was a major leap forward. LINQ to SQL and Entity Framework combined the simplicity of Language-Integrated Queries with the sophistication of Metadata Mapping (Fowler, 2002), making the Domain Model pattern available for mainstream .NET projects. In ASP.NET, both Dynamic Data and MVC can take advantage of the metadata exposed by the LINQ-based frameworks and generate controls or entire pages in ASP.NET applications based on the domain model. Together, these frameworks give web developers powerful, robust, and easy-to-use tools and guidance for implementing data access, business, and presentation logic while reducing code duplication and improving code reuse.

ASP.NET WebForms (with Dynamic Data extensions) and MVC are complementary frameworks that offer unique advantages for different types of web applications. Dynamic Data is a great fit for applications with a large number of similar data-oriented screens, while MVC works better for a small number of unique screens. Most real-world web application projects can benefit from both. Early in the project, Dynamic Data gives you a working user interface, which you can use to discuss the domain model with the business users. As you contine to evolve our understanding of the domain and change the model, Dynamic Data will automatically regenerate the user interface at run time, without forcing you to create and maintain custom web pages. When the domain model is more stable, you can decide which pages have unique requirements and have to be customized. In the end, you may end up replacing some of the web pages with MVC views built on top of the same underlying business and data access logic. The resulting web application can be a mix of a large number of web pages generated by Dynamic Data for maintaining reference data and a small number of unique, public-facing pages implemented in MVC.

The initial version of ASP.NET Dynamic Data, released as part of the .NET Framework 3.5 Service Pack 1, suffered from some short-term limitations and a lingering problem of perception. The fully-featured version, released with the .NET Framework 4, received very little publicity from Microsoft and the developer community focused its attention on the MVC framework instead. This is unfortunate because according to Microsoft’s research at the time of this writing, 80% of existing ASP.NET applications are built with WebForms and could take advantage of the productivity improvements Dynamic Data extensions offer without requiring a rewrite in MVC.

This book is meant to correct some of the perceptions, fill the information gap, and help you see Dynamic Data for what it is—a useful tool in the ASP.NET developer’s toolbox. The first part offers an in-depth look at the Dynamic Data building blocks, shows how they can be used individually to make routine WebForms programming tasks easier, and explains how the components fit together to make dynamic generation of entire pages and websites possible. The second part explains how to solve real-world problems—implementing business logic while keeping it separate from the presentation, extending Dynamic Data components and metadata to make them even more powerful, and much more. I hope you find it useful.

Oleg Sych
February 2012
Oldsmar, Florida