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

We use EntLib on our projects extensively. Generally the blocks we use are data access, logging, exception handling and caching. From time to time, we also use policy injection.

In my estimation, re-inventing those things from scratch would be a complete waste of time. EntLib has thousands of development hours, QA hours and is open source. Using only one or two blocks is still well worth the small amount of overhead associated with deploying the necessary assemblies. But, I'm surprised to hear you don't use logging. Do you use a different logging framework or roll your own?

Answer 2

I think the Enterprise Library is a good choice. Its well documented and used frequently. This is a bonus, especially when you are passing code off to other developers. I don't think you are adding much in the way of overhead or complexity as the it is all packaged pretty well, and installed in the GAC.

Answer 3

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.

Answer 4

Here's a very insightful article on Linq-to-SQL: The Data Access Layer (DAL) Shrinker.

I first started out using Microsoft's Data Access Application Block several years ago. Once Linq was introduced I forced myself to learn it. Since then, I've incorporated it in all future projects.

Answer 5

The enterprise library is not all bad, but the data block isn't that great. So keep most of what you get with the enterprise library. Also note: much of the Enterprise Library is being rewritten right now, including the Data Access Block.
http://www.pnpguidance.net/Post/EnterpriseLibrary50UnityConfiguration.aspx

But for data access you should look at Entity Framework, Linq To SQL (it isn't dead), or NHibernate (check out SummerOfNHibernate.com).

Outside of EntLib, you might also have a look at Prism.

Answer 6

I have nothing against EntLib. In fact I'm using it myself mainly for logging and exception handling on a couple of projects.

As you however noticed data access part of the library gives you very little. Even if the cost of using it in your projects is small (since you already have some experience with it) there still are better data access "products" out there (Linq2Sql, EF, SubSonic, NHibernate, LLBLGen...) that in the long run will save you plenty of time.

Bottom line is: if it's not giving you any major benefits don't include it in a project just because you're used to it. Spend a weekend on one of newer technologies / products and I'm sure it will be of greater benefit than sticking with DAAB.

Answer 7

Personally, I think Enterprise Library suffers software bloat. I wouldn't pick it as a foundational piece "just because". There would need to be a very compelling reason for me to use it on a project. I've used some of the previously released Application Blocks - when they were offered as such - but I've been skeptical about jumping into the full Enterprise Library now just because we were using one piece of many. There's value in keeping complexity to a minimum on a project, and part of a project's complexity are the extra components and libraries that are referenced.

Answer 8

I've struggled with this decision in interactions with several clients. Like most architectural decisions, there really is no wrong or right answer, just a set of trade-offs that need to be applied to different client contexts. When looking at these trade-offs, the decision has usually come down to the following pros and cons:

EL PROs

• Microsoft in the namespace. No surprise that for many large organizations, this is consideration #1. As an aside, many are surprised when they read the EULA and understand Microsoft's actual level of support for the EL.
• Proven at many large scale enterprises across the globe. This doesn't mean that it's the best solution, just that its stable and has a negligible run time performance impact.
• [Data Access] Is probably the best solution if you're looking to stick with old school hand crafted or generated SQL / stored procs

EL CONs

• Slow-to-market or non-existent support for promising practices such as ORM, DI/IoC, or AOP
• Heavyweight with a higher corresponding overhead than other frameworks such as Log4Net in the logging domain.
• Difficult to customize if you step outside the provider model. Dealing with source code changes, signing, and GAC deployments / versioning issues can be much more of a bear with the complex web of EL DLLs than it would be with a lighter weight framework.
• Some of the things that large enterprises have critical needs for, such as a batch framework, haven't made their way to the EL and are still proprietary code in the Avanade ACA framework.

Answer 9

Why not branch out and evaluate SubSonic on a smaller project? Rob Connery works for MS now, and has done a good job creating the "Swiss-Army knife" of ORMS. The project is certainly a know product so you may have better luck introducing it to clients as well as colleauges.

Included in SubSonic is:

• Fluent interface
• Support for MS SQL, Oracle, MySql

• Aggregate queries:

  const double expected = 55.5922;

  // overload #1
  double result = new
      Select(Aggregate.Avg("UnitPrice"))
      .From(Product.Schema)
      .ExecuteScalar<double>();
  Assert.AreEqual(expected, result);
  

  Ramp up time is about a half an hour. If you end up hating it you haven't even wasted a day!

Answer 10

We also use EntLib on all our projects. We evaluated each block independently, and ended up using Caching, Exception Handling, Logging and Validation. We deploy them as local DLLs in the application folder, nice and simple.

Bottom line is, pick and choose what you want. If it looks too bloated, then first check that you are not pulling in more stuff than you actually need.