How to bullet-proof the Data Access Application Block (DAAB)

Microsoft’s Patterns and Practices group have produced a plethora coding patterns in the form of software blocks that has garnered a huge following in the .NET developer space. Of note is the Enterprise Libraries which packages various coding blocks, most notably the Data Access Application Block (DAAB) as a way to standardize the methodologies that architects designate as way to standardize the coding practices.

Over the past 12 months, I’ve noticed a big push towards DAAB as the foundation for .NET Framework data access strategies. In numerous conversations during my normal day to day interactions with customers, whether at conferences such as Tech Ed, face to face meetings or over the phone I’ve noticed a clear pattern emerging; the motivations of each architect are almost always different, but the goal is the same: build a ubiquitous common data access layer for use of all applications.

For a moment lets also consider the pulse with the .NET developer community: All activity seems suggests that the DAAB pattern has reached a tipping point and is being picked up as the defacto standard way to abstract your application away from the plumbing ADO.NET code even over and above the common programming model delivered in ADO.NET 2.0.
Numerous resources exist on how, where and when to use DAAB. Take a look at these blogs, documentation and articles for details.

To build a truly ubiquitous data access layer, DAAB is an agreeable technical basis for .NET implementations. DAAB provides a clean interface driven leveling of data sources, but your client applications still remain badly exposed where SQL leveling is concerned.

So what is SQL Leveling and why does it matter to me if I want to become the rock star and deliver a truly future-proofed data access layer for my organization?

By definition, SQL leveling provides the capability to write a SQL statement that can be executed across multiple data sources, regardless of the data sources SQL implementation. If any of applications that uses your data access layer has to made even one coding consideration based on what data source it might be talking to, the value of your data access layer is quickly eroded.

Over the course of the next few postings, I will explore various aspects of SQL Leveling and hopefully leave you in little doubt that anyone serious about building a data access block with the Microsoft Enterprise Libraries Data Access Blocks cannot afford to ignore SQL Leveling.