DAAB in Enterprise Library for .NET 2.0

  • Article

Here we go again – another Data Access Application Block (DAAB). Those of you who have been following our team and using our stuff for a while probably know that DAAB was the first code-based deliverable that we produced, and was also the first ever “application block”. And while many of our later blocks offer more functionality and address more glamorous scenarios, DAAB still remains our most popular application block today. Why? First, data access is something everybody spends a lot of time on. Second, the block has always been simple. Sure, it’s got a lot more to it that the original DAAB (which had just one class, SqlHelper), but it’s still very easy to learn and use.

Design Goals

The overall rationale behind the DAAB has always been the same: to cut down the amount of code you need to write for the most common data access scenarios. It does not attempt to hide ADO.NET or implement all ADO.NET scenarios, and all of the power of ADO.NET is always available to use from the DAAB. However we’ve found that most developers, most of the time, are doing the same basic data access tasks. The DAAB cuts down the amount of code you need for these tasks, and in the process cuts down on common mistakes such as failing to close the connection, or not storing and protecting connection strings correctly.

The upcoming release in Enterprise Library for .NET Framework 2.0 is a relatively minor update to the existing Enterprise Library DAAB. It will support the same key scenarios, but it’s been redesigned to leverage some new features in .NET Framework 2.0, and to sport a simpler architecture. In addition, we’ve made some minor changes to the block based on your feedback, in particular around being able to use the block without configuration files. Most of these changes are already in place in the August CTP release (available on the EntLib Community site), but we still have a bit of work to do, especially around the configuration design-time and instrumentation.

Key Changes

So what’s new in the upcoming release? Here are some of the bigger changes:

Use with or without configuration

The first two versions of DAAB didn’t provide any support for connection string management; this was left as an ‘exercise for the reader’. The first Enterprise Library releases addressed this potential problem by using the Configuration Application Block to manage the connection strings, requiring developers to use logical instance names from their code. While this solution worked well for most developers, we’ve been told we swung the pendulum too far in the other direction by not providing an easy way for people to manage their own connection strings, for example where these are created dynamically.

So the great news is that the new DAAB will support the best of both worlds. You’ll still be able to create Database references using either a default or named instance, using the same familiar syntax:

Database db = DatabaseFactory.CreateDatabase();
Database db = DatabaseFactory.CreateDatabase("Northwind");

However, if you know the type of database you want, and the connection string, you will be able to ‘new up’ the Database objects directly, without using configuration at all:

SqlDatabase sqlDatabase = new SqlDatabase(myConnectionString);
GenericDatabase db = new GenericDatabase(connectionString, OdbcFactory.Instance);

(More on the GenericDatabase later). Once you have your Database instance, you can use it the same way, not matter how you got it.

Integration with the <connectionStrings> section

.NET Framework 2.0 includes a new <connectionStrings> section in the configuration files, which looks like this:

<connectionStrings>
  <add name="Sales"
       providerName="System.Data.SqlClient"
       connectionString= "server=myserver;database=Products;uid=salesUser;pwd=sellMoreProducts" />

  <add name="NorthWind"
       providerName="System.Data.SqlClient"
       connectionString="server=.;database=NorthWind;Integrated Security=SSPI" />
</connectionStrings>

This information can also be easily accessed programmatically using ConfigurationManager.ConnectionStrings. It doesn’t take a genius to see that this configuration information is pretty similar to what we already have in Enterprise Library today. So rather than give you two different ways of managing database connections, the new DAAB will make use of this section. DAAB will still have some optional configuration sections for some advanced functionality like Oracle package mapping, but for most scenarios this simple section is all that you need. (Note: this feature isn’t implemented in the August CTP release, which still uses its own section for the connections, but this will be changed in the final release).

Updated design with ADO.NET 2.0 features

ADO.NET 2.0 provides some important new features that have allowed us to simplify the design of the DAAB. For example, the new DbProviderFactory and its provider-specific subclasses are now used to create the commands and connections used by the block. In addition, to simplify the architecture we have eliminated DbCommandWrapper class in the previous Enterprise Library DAABs. As a result we have moved the methods that were on DbCommandWrapper have been ‘promoted’ to the Database class. This should be the only breaking change from the previous Enterprise Library DAAB.

GenericDatabase

In the previous Enterprise Library DAAB versions, it was necessary to have an EntLib Database-derived class for every ADO.NET managed providers. We included Database classes for SQL Server, Oracle and DB2, but if you used any other managed providers, you were out of luck (or at least needed to find or build your own Database class).

In the new version, we still have the SqlDatabase and OracleDatabase class – but we also have a new GenericDatabase class. The GenericDatabase can be used with any .NET managed provider (including the ODBC and OLE-DB providers that ship with .NET) – but the catch is that it doesn’t support all of the DAAB functionality. Most significantly, the overloads that use parameter discovery do not work (since these methods aren’t supported on .NET’s DbConnection or DbCommand classes). There’s still the option to build your own Database-derived classes to support this advanced functionality and provide improved database transparency – this is why we built SqlDatabase and OracleDatabase – but at least you’ll be able to use most of the block against any type of database.

And in case you were wondering what happened to DB2, at the moment we are not aware of any ADO.NET 2.0-compatible managed providers. Hopefully these will exist soon, but in the meantime OLE-DB should be an option.

Design Diagram

The following diagram shows the key classes in the new Data Access Application Block.

DAAB Design

I hope this description has been helpful. Feel free to provide feedback on this post or on the EntLib Community site.