using older Data Access Application Block alongside newer Enterprise Library

Question

Is there any reason I can't use an older version of Data Access Application Block (sqlhelper) along with Enterprise Library (if I'm not using the data parts of it?)

Answer 1

EnterpriseLibrary is broken up into several different dlls, so you don't even need to reference the parts you don't want. Even if they are referenced, there's nothing at all preventing you from mix and matching.

If you do come across cases where you have multiple classes with the same name referenced in the same class, just explicitly name them (or via a using statement) to make sure you grab the right object type.

Remember, the fully qualified name of an object includes its namespace, so SqlHelper in one isn't the same as SqlHelper in the other as long as you include the namespace.

Have fun!

Answer 2

I don't see why you can't ~technically do it. But it seems strange that you don't want to convert it.

The "cleanness" of the EnterpriseLibarary.Data framework is very appealing.

It also makes very "clean" code. Example:

    public override IDataReader CustomersGetSingleWithOrdersReader(string customerId)
    {
        IDataReader returnReader = null;
        try
        {
            Database db = this.GetDatabase(); //encapsulate call to retrieve a database object, very simple routine
            DbCommand dbc = db.GetStoredProcCommand  ("dbo.uspCustomersGetSingleWithOrders);
 db.AddInParameter(dbc, "@CustomerID", System.Data.DbType.String, customerId);
            returnReader = db.ExecuteReader(dbc);
            return returnReader;
        }
        finally
        {
        }
    }

You care about 2 things in the above code. Which stored procedure to call. What parameters to give it. The EnterpriseLibrary.Data does the rest for you.

From my experience, the only thing the EnterpriseLibrary.Data cannot protect you from (because it can't in this situation) is using an IDataReader AND THEN NOT CLOSING IT. That's a big no-no.

But as previously mentioned, fully qualified namespaces and such will get you around the issue.

Don't forget that the EnterpriseLibrary.Data framework is more mature than the original DAAB.

And don't forget one of the bugs on DAAB 2.0.

http://weblogs.asp.net/rosherove/archive/2003/07/29/10614.aspx