//A Case For and Against the Enterprise Library

A Case For and Against the Enterprise Library

I’ve been an architect for a while now, but, as far as being an architect within the walls of Microsoft, today was day one.

Already, I’ve run into an interesting issue: when it is better to forgo the code of the Enterprise Library and roll your own, vs. using existing code.

Roll your own what?  Well, the MS Enterprise Library is a set of source code (in both VB.Net and C#) that provides an infrastructure for business applications.  The “blocks” that are provided include: caching, configuration, data access and instrumentation, among others.

I know that many people have downloaded the application blocks.  I don’t know how many people are using them.  I suspect far fewer.

I took a look at the blocks myself, and my first impression: unnecessary complexity.  Big time.  This is what comes of creating a framework without the business requirements to actually use it.  To say that the code has a high “bus” factor is a bit deceptive, because along with the code comes ample documentation that should mitigate the difficulty that will inevitably come from attempt to use them.

On the other hand, the code is there and it works.  If you have a project that needs a data access layer, why write a new one when a perfectly workable, and debugged, application block exists for it? 

Why indeed.  I had a long discussion with a developer today about using these blocks.  I will try to recount each of the discussion points:

  1. The blocks are complex and we only need to do something simple.  True: the blocks are complex, but the amount of time needed to do something simple is FAR greater than the amount of time needed to understand how to configure the blocks.  If you look at simple project impact, using something complex is still less expensive that writing something simple.
  2. We don’t know these application blocks, so it will take time to learn.  True: but if you write new code, the only person who knows it, when you are done, it you.  Everyone else has to read the documentation.  You’d be hard pressed to come up with better documentation than the docs delivered with the application blocks.
  3. The code we write will meet our needs better because we are doing “special” stuff.  False: the stuff that is done in the application blocks is pure infrastructure.  As an architect, I carry the mantra: leverage existing systems first, then buy for competitive parity, and lastly build for competitve advantage.  You will not normally provide your employer with a competitive advantage by writing your own code in infrastructure.  You are more likely to get competitive advantage by using the blocks, since they will be less expensive with capabilities right out of the box.
  4. We don’t need all that code.  True.  Don’t use the functionality you don’t need.  The cost is very low to ignore the functionality you don’t need.  More importantly, writing your own code means debugging your own code.  If you leverage the code that is there, you will not have to debug it.  That saves buckets of time.
  5. Our code can be tuned and is faster than the code in the Enterprise Library.  The code in the Enterprise Library is tuned for flexibility, not speed.  This is true.  However, when you first write your own code, it is slow.  It gets faster when you tune it.  Why not jump right to the tuning step?  Put in the EL for the component you are interested in, run a stress test against it, and fine-tune the code to speed it up.  You have unit tests already in place to prove that your tuning work won’t break the functionality (highly valuable when doing perf testing). 

Please… can someone else come up with any better arguments for NOT using the application blocks in the enterprise library?  I’m not seeing one.

 

By |2005-08-01T22:58:00+00:00August 1st, 2005|Enterprise Architecture|16 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

16 Comments

  1. Karl August 2, 2005 at 12:17 am - Reply

    I can give you a specific example, perhaps you can generalize it.

    I wrote a 2-part localization framework article (part 1: http://www.codeproject.com/aspnet/localization_websites.asp) Every now and then I get people asking about my approach vs the localization enterprise library (which I don’t think existed @ the time). Almost always people weren’t happy with the libraries implementation…it used reflection, they didn’t like that…it used an RDBMS, they didn’t like that, it didn’t go far enough to provide a simple extensability framework (ie, custom server controls).

    Frankly, I think it all comes down to having a relatively simple to understand solution with good documentation (you and I might see highly differently on what’s good documentation for your average-joe programmer), some samples that get people up and running and some useful code that sits outside the architecture(again, controls).

    I think people read about or know one solution, and it makes perfect sense to them…and then when looking at the application blocks, they are always comparing it against what they know/understand…it’s an uphill battle. It isn’t a time issue (your #1), it’s just a human nature :).

    I can say as a O/R mapper guy, the reason I hate the DAL block is because I can’t stand having my code publically expose something that returns an untyped dataset…what if one of my developers uses it?! My view of a DAL is one that returns a "User" not a "DataReader".

  2. Andy August 2, 2005 at 12:58 am - Reply

    The biggest argument for NOT using them is

    "My developer EGO is so big I think I can code better than you".

    Each of the arguments above can be applied to The .Net framework and I doubt any of the developers are suggesting they write their own version of that (though I have met a few!)

    #5 can probably be countered by pointing out that most enterprise applications do not need to be massivly tuned for performance, and should never be done in advance… measure first (See Rico)

  3. Joe Chung August 2, 2005 at 1:02 am - Reply

    Data stores configured for SQL Server only with no SQL scripts provided for data storage on other RDBMS’s like ORACLE, DB/2, MySql, etc.

    I don’t fault MS for this, but it’s an argument for not using the Enterprise Library if the rest of your application uses another data store.

  4. Uwe August 2, 2005 at 1:17 am - Reply

    Not using, because:

    – Already did my own

    – Don’t know whether it is a "side"-product developed by some MS people in their spare-time and therefore whether it is 100% reliable/designed (WTL, anyone? ;-).

    – Don’t know whether still usable in the next Framework version

    – Don’t know whether it will be supported in the future (like e.g. MFC-way, just fixes, no major upgrades…)

  5. Jan Schreuder August 2, 2005 at 1:39 am - Reply

    I totally agree. The discussion points make very valid arguments for using the Application blocks. And it applies to every type of ready made class library or framework. My argument for using the application blocks has always been: It’s there, it’s tested, it works!

  6. Daniel Rieck August 2, 2005 at 4:07 am - Reply

    What if I already have a running and working system? What benefit would I have if I threw all that away and used the Enterprise Library?

    Granted, I don’t have all the functionality provided by EL, but so far I didn’t need it.

  7. Paul Wilson August 2, 2005 at 7:25 am - Reply

    Data Access: There are several very good O/R Mappers that are simpler and which provide more functionality.

    Instrumentation: Log4Net is pretty much accepted by most as being easier, more performant, and more of a standard.

    Those are typically the big two blocks, and neither of them fair well when compared to other off-the-shelf "blocks". I believe there are also some 3rd party "blocks" that compare well with some of the others in EL, but I can’t claim to know that personally since I just don’t find building the other "blocks" myself to be difficult at all, especially once you don’t have to worry about the complexity inherent in the EL. So I just don’t see any reason to use the EL when there are better and simpler "blocks" that are readily available.

  8. Edijer August 2, 2005 at 8:17 am - Reply

    In point #1. Do many developers really think the EntLib blocks are that complex to use? If you try to extend it with custom functionality I guess it is somewhat complex. But the basic functionality? Hard to believe. From my experience you can learn and readily use most of the blocks in a day or two. Well, the good documentation is a factor. I’m just wondering

  9. Steve Owens August 2, 2005 at 1:21 pm - Reply

    I am absolutely in favor of using proven code whenever possible. This is clearly true of EntLib. My only thought is, what if there was a simpler framework? Greater flexibility means greater complexity – what if we traded some flex for less plex? There are some parts of EL that have already been written and tested, some of which may be equal in ussability. Logging and configuration are two that come to mind that have easier-to-grok counterparts.

  10. Mickey Gousset August 2, 2005 at 4:36 pm - Reply

    The only application block that I currently use is the Data Access Block v2, but I tell ya, I can’t live without it. I personally think it makes the code much cleaner and easier to read. And with all the developers in my shop using the same method of data access, it makes it easy for any of us to get a better understanding of the other’s code.

    I do need to investigate the other application blocks, but if you have not looked at any of them, I recommend starting with the Data Access block.

  11. Mickey Gousset August 2, 2005 at 4:59 pm - Reply

    I’m sure by now you have heard of the Microsoft Application Blocks. These are sets of source code which…

  12. Daniel Melo August 2, 2005 at 6:04 pm - Reply

    My only experience with Microsoft application blocks was, actually, with data access application block 2.0, release before the enterprise library.

    In that version, some features I would like to have were not implemented, and we wrote a "layer" on top of it, adding the extra features we wanted to have.

    The discussion point in our team was about : Change the application block source code x Extend the application block.

    After all, we decided to never change the code of an app block, in order to easily update them (as soon as new realeases were coming up).

    Only the data access application block was really used in the final version of our project, but we did considered using the configuration application block. Althought, the version of conf. app block we had studied was not well designed, and poorly written in our opinion. In the end, we built our own for that purpose.

    Now we are studying the User interface application block.

  13. A Case For and Against the Enterprise Library: Already, I’ve run into an interesting issue: when it…

  14. A Case For and Against the Enterprise Library: Already, I’ve run into an interesting issue: when it…

  15. A Case For and Against the Enterprise Library: Already, I’ve run into an interesting issue: when it…

  16. tomholl August 11, 2005 at 8:44 pm - Reply

    I’m the Product Manager for Enterprise Library, and it’s great to hear people’s thoughts on the value of using the library. Our team’s thoughts on when and why to use Enterprise Library are pretty consistent with what Nick has posted. I also accept that parts of EntLib are more complex than we’d like – there is a tradeoff between flexibility and complexity that can be a tricky tightrope walk. The good news is that some of the changes in .NET 2.0 will enable us to significantly simplify many parts of the next version of Enterprise Library.

    I did want to respond to some of Uwe’s comments above:

    – Already did my own

    Sure – "don’t fix it if it ain’t broke" is a great argument, particularly for existing applications. Still, many customers find that developing and maintaining their own reusable code library can be expensive, so using Enterprise Library may help to minimize this cost.

    – Don’t know whether it is a "side"-product developed by some MS people in their spare-time and therefore whether it is 100% reliable/designed (WTL, anyone? ;-).

    Enterprise Library is developed by the Microsoft patterns & practices group, which is a team of about 30 employees and a varying (but pretty large) number of vendors and contractors. There are about 6 of us who have worked on Enterprise Library more or less full time for the last year. So it’s not a spare time project 🙂

    – Don’t know whether still usable in the next Framework version

    The June release can be made to work with VS2005/.NET 2.0 now, but it doesn’t leverage any new features. We are working on a new version now that will be designed for VS2005/.NET 2.0.

    – Don’t know whether it will be supported in the future (like e.g. MFC-way, just fixes, no major upgrades…)

    See the "What is Guidance?" and "Feedback and Support" sections on http://msdn.microsoft.com/practices/default.aspx?pull=/library/en-us/dnpag2/html/entlib.asp for details about how we support guidance deliverables such as Enterprise Library.

Leave A Comment

19 + 20 =