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.

So you know, with SubSonic you can execute Stored Procs and return a strongly type list of objects - it will do the lightweight reflection for you and build your List. — David Robbins, Jul 03 '09 at 01:48

score 8 · Accepted Answer · answered Jul 01 '09 at 15:49

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.

score 8 · Answer 2 · answered Jul 01 '09 at 15:57

8

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.

answered Jul 01 '09 at 15:57

Chris Brandsma

11,383
5
46
58

2

The DAAB's purpose in life was to reduce the grind involved in hacking out the usual boiler plate code for accessing SP's, running parameterised queries and the like. It was never meant as an ORM type layer. It's served it's purpose well I think. – Kev Jul 01 '09 at 16:40
2

The scope has grown a bit since it was just one class called SQLHelper. But at the core, SP abstraction is one of the most significant benefits to me. The larger goal of database agnostic calls, doesn't resonate with me. I just don't see an Enterprise suddenly deciding that they want to switch out the underlying database to a different technology -- and if they do, they will have a ton more work than just updating a DAL. – Josh Jul 01 '09 at 17:44
1

An Orm isn't just about making it easier to switch databases. That is merely a perk -- not the end goal at all. The main purpose of an ORM is to abstract the database to make database interaction code easier to write, maintain, and test. Even if you are a "Stored Proc Only" shop, you could probably still benefit greatly from a good ORM strategy. – Chris Brandsma Jul 01 '09 at 19:09
URL seems to be dead. – Rand Random Feb 25 '15 at 14:05

score 6 · Answer 3 · answered Jul 01 '09 at 15:47

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?

I created a basic logging library when .Net 1.0 was released, and with minor revisions, have found it fits our needs. — Josh, Jul 01 '09 at 16:02

score 5 · Answer 4 · answered Jul 01 '09 at 16:02

5

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.

answered Jul 01 '09 at 16:02

Chris W. Rea

5,099
36
53

1

I dunno, the DAAB blocks seem lightweight enough. – Kev Jul 01 '09 at 16:29
You can also only use what you need. You eliminate any bloat from the other blocks by not even referencing them. – paulwhit Jul 01 '09 at 16:40
Enterprise Library as a whole just hasn't struck me as very approachable. If these pieces *are* easily usable separate from one another, why were they packaged together...? It seems like bloat to me, even while individual parts may have merit. I'm also concerned a team drawn into Enterprise Library for one particularly compelling feature -- or, worse, for no reason other than it comes from Microsoft -- might end up using other EL features on weak reasoning, as opposed to taking a simpler approach or sourcing alternate best-of-breed components. – Chris W. Rea Jul 01 '09 at 17:50
1

@Kev and @Paulwhit are correct that you don't have to reference the modules you don't want to use, but to use the DAAB, you have to reference both the Data and the Common dlls, both of which have a significant amount of coding. – Josh Jul 01 '09 at 17:53
@Chris: I am looking for an exception handling framework. I came across the exception handling block. You advised not to use it, then what would you advise I use for an exception handling framework? – Brendan Vogt Mar 09 '11 at 06:46

score 4 · Answer 5 · answered Jul 01 '09 at 16:32

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.

Not sure I follow what you mean by "Slow-to-market or non-existent support for promising practices such as ORM, DI/IoC, or AOP". Isn't the Enterprise Library Unity block actually an IoC itself? And isn't PIAB similar in many ways to AOP? The DAAB, from what little I've seen looks horrible compared to an ORM like the EF. I'd venture to go so far as saying the DAAB and the Cryptography block obsolete in fact. — Simon Brangwin, Aug 19 '09 at 01:46
I see Unity as a 1 -2 year delayed reaction to the trend started by the Spring framework [Java]. I use Unity at a client's preference. Given a choice, there are other options in the .NET world that are easier to deal with, more fluent, and lighter weight. EF gives you a flavor of AOP. Once again, I'd lean towards something like PostSharp if real work needs to get done. In terms of ORM, even many .NET folks are not big EF fans. NHibernate has just been around longer, is more flexible, and (to this point) more innovative. — Thomas Beck, Aug 21 '09 at 08:16
I see your point now and in the past that has certainly been true. However, EntLib v4.1 seems to have caught up and v5 is soon to be released. And EF v4 with POCO support is working well for our project so far. So to provide advice to the OP for the present and foreseeable future, I would definitely recommend EntLib and EF because most of the cons you bring up are no longer true. — Simon Brangwin, Aug 23 '09 at 22:49
DAAB was never meant to be an ORM. It solves a different purpose. By the way, Enterprise Library 6.0 shipped last week. Take a look http://aka.ms/el6announce — Grigori Melnik, May 01 '13 at 04:14

score 3 · Answer 6 · answered Jul 01 '09 at 15:57

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.

If you're not using one of the mappers such as SubSonic etc, and you're just working with raw DataReaders, SProcs etc, DAAB is still worth using. I find it a huge time saver and it reduces the amount of code I have to write. It's a well factored tool that takes the grind out of having to build DbCommands, DbAdapters etc. — Kev, Jul 01 '09 at 16:36

score 3 · Answer 7 · answered Jul 01 '09 at 19:12

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.

score 2 · Answer 8 · answered Jul 01 '09 at 15:47

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.

score 2 · Answer 9 · edited Dec 21 '11 at 21:19

2

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 my projects.

edited Dec 21 '11 at 21:19

David Clarke

12,002
8
80
105

answered Jul 01 '09 at 15:50

jinsungy

10,239
24
68
78

That link didn't work but this does for the moment: http://www.adamtibi.net/08-2008/linq-to-sql-the-data-access-layer-dal-shrinker – DOK Jan 21 '11 at 20:16
Fixed the link in original answer – David Clarke Dec 21 '11 at 22:54

score 2 · Answer 10 · edited Feb 28 '17 at 16:22

2

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!

edited Feb 28 '17 at 16:22

Neolisk

23,880
16
72
135

answered Jul 01 '09 at 16:34

David Robbins

9,964
7
47
81

Any idea of what the install base is for SubSonic? – Josh Jul 02 '09 at 18:37
Unfortunately no. Your best bet is to inquire at the site's forums. – David Robbins Jul 03 '09 at 01:46

Continue with Microsoft Enterprise Library?

Update:

10 Answers10