DAAB Wrapper

Topics: Data Access Application Block
Jan 5, 2007 at 6:34 AM
I looked at DAAB Ent LIb 2.0 January 2006 release. But I did not want to sprinkle the DAAB DLLs all over my different applications. Also, I wanted to de couple my dependency
on DAAB such that when a newer version comes and there are breaking changes, I can make
those changes only in the wrapper and not in all my projects.
Hence I wanted to create a wrapper on top of it.
I created a wrapper allright, my idea was that I would return data readers, datasets
and adapters from the wrapper. I would then use this wrapper in my app logic layer to get/set data.
However, as the reader requires an active connection, I could not pass it through layers.
Same for Command objects.
I could, however, pass the data table from the populated dataset.
Then I exposed a GetConnection method from the wrapper and returned the conn object.
I would then use it in App Logic layer to create a datareader etc.
However, this approach seems like a hack rather than an elegant solution.
Any ideas about how I can go about this?
Jan 5, 2007 at 10:10 PM
You could use an O/RM, that hides most of the data access code from the front end. That way if the EntLib changes (and the O/RM keeps pace), you shouldn't have to make many (or any) updates to your front end code.

Jan 13, 2007 at 4:08 PM
My suggestion would be to not bother wrapping the DAAB because I think you won't get much bank for your buck for a few reasons.

First, there have not been any breaking changes in the DAAB to date. It has been pretty stable since its release and the updates occurring have just been additive.

Second, you have the source code, which gives you more power and options than if you just had the binaries.

Third, all the software factories pretty much depend on the Enterprise Library, so my guess is that any changes will be done in such a way to alleviate too many breaking changes.

Fourth, the Patterns and Practices team has been pretty good about documenting strategies for migration between versions of the application blocks.

Obviously there are no guarantees, but I don't see breaking changes being an issue with the DAAB.

As always, however, you should architect your application wisely against changes in 3rd party components. Minimizing code redundancy, maintaining a cohesive DAL, and having unit tests will go along way to minimizing the impact and effort of any changes occuring in your applications. This is not just true of Enterprise Library, but all your dependencies in your applications.




David Hayden
Microsoft MVP C#
Jan 13, 2007 at 4:37 PM
With respect, David, moving from the DBCommandWrapper in EL 1 to DbCommand in EL 2 definitely falls into the "breaking change" category...
Jan 13, 2007 at 6:38 PM
Good point, but I don't consider that a "breaking change" because the EntLib team came out with a patch that allowed Ent Lib 1.1 applications to run on .NET 2.0 with no code changes.

If one decided to later port the application to .NET 2.0 and take advantage of .NET 2.0 features, the change of any existing code to use DbCommand in the DAAB was perhaps the least of one's concerns.

My recommendation is to think about how the ADO.NET Entity Framework, LINQ, and LINQ to SQL will play in your applications and not so much about a wrapper for the DAAB.

Just my thoughts...




David Hayden
Microsoft MVP C#
Mar 5, 2008 at 1:54 PM
Has anyone got any info as to when or if EL will support LINQ in the data access layer?