Vision and Design Goals

Designing an application block should not be approached any differently than designing any other software developed in an enterprise. As such, the first step to designing the application block should be determining what the vision and design goals for the application block are. If you read through the documentation that is provided for any of the application blocks that ship with Enterprise Library, you will see that one of the first details that are documented is the design goals for that block. This should not be any different for an application block that you create.

In this chapter I am going to create an application block that subscribes to the best practices published by the Microsoft patterns & practices team with respect to data access logic components. In some sense, this application block can be thought of as a level of abstraction above what the Data Access Application Block provides. If you read Chapter 3, you should understand that it is an implementation for simplifying the use of database providers (also known as data access helper components) in the data layer of an application. The Data Access Application Block implements the recommendations for database providers as published by Microsoft's patterns & practices group.

While database providers are extremely useful, they do not address all of the areas of guidance for designing the data layer of a distributed application. Unfortunately, the code that uses database providers is often scattered throughout many different places in an application, embedded in the actual business entity, or "utility" classes are created in an application that retrieve and update data regardless of the type of data (e.g., user information, reference data, transactional business data) with which it is working.

As mentioned at the end of the Chapter 3, a recommended design for an application is to create data access logic components (DALCs) that have the responsibility for populating business entity classes or DataSets with data and propagating changes in them back to the database. Data access logic components are a recommended best practice for accessing business data because they provide a simple programmatic interface for retrieving and performing operations on specific types of data. Data access logic components typically provide methods to perform Create, Retrieve, Update, and Delete operations relating to a specific business entity in an application (e.g., customers). Additionally, the logic for how the fields (e.g., customerID, customerName, etc.) in a particular business entity or DataSet map to a stored procedure's parameters or columns in a database table can be encapsulated by a data access logic component. By encapsulating this logic in data access logic components, you can achieve greater reuse throughout different types of applications with different types of clients.

The following sections walk you through the steps for developing and testing an application block that subscribes to the best practices for supporting data access logic components in an application. A major feature of this block is that it allows the DataFields in a typed DataSet to be mapped to the parameters for a stored procedure, thus making it possible for the in-memory objects to need no knowledge of the database schema or that a database is even present. Martin Fowler defines such an object as a Data Mapper^[1]; therefore, I have named this application block as the Data Mapping Application Block. Its design goals are to provide:

^[1] Martin Fowler, Patterns of Enterprise Application Architecture, p. 165. Addison-Wesley, 2002.

• The ability to eliminate code that couples stored procedure parameters to the DataFields in a typed DataSet

• Capabilities to map stored procedure parameters to values that are not known to the system until runtime

• Support for performing database operations against multiple database tables in the scope of a database transaction

• Ability to cache business data in a data access logic component

• Support for setting command properties (e.g., command timeout) through configuration instead of code

In short, the design goals for the Data Mapping Application Block are to provide an interface that simplifies the creation of data access logic components while still subscribing to the best practices as detailed in the Application Architecture for .NET: Designing Applications and Services publication.^[2] For example, this application block should make it easy to ensure that database operations occur in the scope of a transaction or specify whether business data should be cached by the data access logic component. The vision for this block is that using this application block will free developers from having to deal with such operational issues and instead allow them to concentrate on adding business logic.

^[2] Found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp.

Many classes exist in this application block to address the design goals and vision. There are too many to cover in a chapter that also addresses how to build an application block. Therefore, this chapter highlights the salient tasks that I needed to undertake to build this block so that you can understand what is involved with building your own custom application blocks. For detailed information on the design of the Data Mapping Application Block and how to configure and develop an application to take advantage of it, please read Appendix A and visit the book's Web site or the workspace that I created for this application block on www.gotdotnet.com.