Continue with Microsoft Enterprise Library?

Question

I've been using the Microsoft Enterprise Library since before it was labeled as such for abstracted data access, in place of writing my own DAL. Originally I was just importing one file (sqlhelper.cs) into my projects, but then the later releases required that I reference the whole dll, unless I wanted to put a good deal of work in removing the functionality I wanted.

I assume a new version of Enterprise Library will be released a few months after .NET 4.0 is released. My company’s usage of the library is likely different from the traditional use, we design and develop web and windows applications for a number of clients. We either hand off the finished projects to internal developers to maintain, or if it is a smaller client, we'll maintain the applications.

Because of the nature of the business, I'm fortunate enough to "start from scratch" a good deal of time when designing a new application, opposed to being tied to updating the same codebase. The next project I will likely ask the same question of myself, should we use the Microsoft Enterprise Library again? We only use the Data Access Blocks, and it does seem save time during development. At the same time, I wonder how much overhead and complexity I'm adding to the project by using the objects.

Thank you in advance for your suggestions.

Update:

The discussion here really has me reconsidering the issue -- it might be less about lightweight abstractions for accessing Stored Procs, but a larger architectural question on why we’re still tied to the N-Tier model.

To me if comes down to what a database is used for in the application. In the classic 3-Tier/N-Tier world, the database is an independent storage of company information. Different applications (Web, Desktop, etc.) all share and access a common storage platform. In this scenario, stored procedures make sense because they act as a layer of abstraction between the various applications and the tables.

For other projects, the database is the exclusive persistent storage of the larger application. The UI or other types of access (including Web Services, Remoting, etc.) are required to go-through the BLL of the application. This is the scenario we more commonly develop for, because of the nature of our business.

Given this conclusion, I'm going to create two prototype projects, one using SubSonic and the other LINQ. Although I’m concerned about the overhead and loss of fidelity with LINQ, the significant reduction of code needed for data access and the alignment to the type of projects we develop, make it worth a look.

Answer 1

ALL data access layers have their up and down sides. As a contractor, I run into a wide range of projects. Every project I've personally started, I've used the Enterprise Library Data Access Blocks calling S'procs. It's pretty quick to get up and going, but more than that: I'm extremely familiar with it. The downside, of course, is the amount of code you have to write.

A couple of recent projects I've been attached to are using LINQ / PLINQO. Granted the editor support is great and it creates most of the code for you, I'm not impressed with it's survivability for inflight database changes nor am I impressed with the hoops you have to jump through to get decent performance out of it.

Honestly, you should branch out and try something new. That's the only way to find the pitfalls of each type and really be able to make informed decisions about which tool you want for the job.