• Choose a category
• All
• Classic-Fiction

Who does really write the DAL? Is it you? And why should you write a DAL yourself? Is it perhaps that you have a strict nonfunctional requirement that explicitly prohibits the use of an ad hoc tool such as an O/RM? Or is it rather that you think you would craft your DAL better than any commercial O/RM tools?

Figure 14-7. A conceptual view of the DAL’s interior.

In a domain-based world, a well-built DAL is nearly the same as a well-built O/RM tool. So unless you have strict nonfunctional requirements that prohibit it, you should use an O/RM. Entity Framework is the official O/RM tool you find in the Microsoft stack of technologies. NHibernate is an even more popular tool that has been around for quite a few years now and that is close to its maturity.

Interfacing the DAL

In some simple scenarios, it might be acceptable for the DAL to be invoked from the presentation layer. This happens when you actually have only two tiers: the presentation layer and the storage. Beyond this, the DAL is a constituent part of the back end and is invoked from the application logic.

The next issues to resolve are the following: Should you allow any service layer classes to know the nitty-gritty details of the DAL implementation? Should you wrap the DAL implementation in an interfacing module that provides a fixed interface regardless of the underlying details? As usual, it depends.

Support for Multiple Databases

In the past, every architect would have answered the previous questions with a sounding yes. Today, it is likely the same answer, but for different reasons. For years, the primary reason for wrapping the DAL in the outermost container has been to achieve database independence.

Wrapping the DAL in a pluggable component greatly simplifies the task of installing the same application in different servers or using it for customers with a different database system.

Today, the advent of O/RM tools has dwarfed this specific aspect of the DAL. It’s the O/RM itself that provides database independence today. At the same time, other compelling reasons show up that make interfacing the DAL still a great idea.

The Repository Pattern

A common way to hide the implementation details and dependencies of the DAL is using the Repository pattern. There are a couple of general ways you can implement the pattern. One consists of defining a CRUD-like generic interface with a bunch of Add, Delete, Update, and Get methods. Here’s an example:

public interface IRepository : ICollection, IQueryable

{

public void Add(T item)

{ ... }

public bool Contains(T item)

{ ... }

public bool Remove(T item)

{ ... }

public void Update(T item)

{ ... }

public IQueryable Include(Expression> subSelector)

{ ... }

}

The type T indicates the type of entity, such as Customer, Order, or Product. Next, you create an entity-specific repository object where you add ad hoc query methods that are suited for the entity. Here’s an example:

public interface IProductRepository : IRepository

{

IQueryable GetProductsOnSale();

}

Classes in the service layer deal with repositories and ignore everything that’s hidden in their implementation. Figure 14-8 shows the summarizing graphic.

Another approach to building a repository consists of simply creating entity-specific repository classes and giving each one the interface you like best.

Today, testability is an excellent reason to interface the DAL. As shown in Figure 14-8, it allows you to plug in a fake DAL just for the purpose of testing service layer classes. Another scenario, however, is gaining ground on popularity: upgrading the existing DAL based on an on-premises database for the cloud.

Figure 14-8. The Repository pattern applied to the DAL.

Using an Object/Relational Mapper

So it seems that a common practice for implementing a DAL is using an O/RM. Using an O/RM is not trivial, but tools and designers in the Microsoft and Visual Studio world make it considerably