Advantages and disadvantages of using Enterprise Library

Question

Im just starting a project and since this project is personal I was wondering what are the advantages of using Enterprise Library? We use the version 2 for several projects in t

Answer 1

For the database application block, the main advantage is that it makes it easier to produce database-agnostic code. The developer interacts mainly with generic Database and DbCommand objects, rather than eg SqlConnection, SqlCommand, etc. Thus, switching to a different database (ie Oracle) becomes more feasible. Depending on your business needs, this could be a definite advantage. EntLib also gently prods the developer in the direction of using DbParameter for query parameters, which reduces the risk of SQL injection attacks.

As another poster mentionned, the data app block is somewhat higher-level than the straight ADO.NET classes, so it tends to require fewer lines of code to do the same thing.

From my point of view, the data, exception and logging blocks are the most useful. Exception and Logging together make it very easy to log exceptions (duh) to a number of places and in a number of formats. For example, they can put the entire exception log entry, including the stack trace, in the Windows event log making it relatively easy to diagnose a problem.

One disadvantage of EntLib is that some app blocks place quite a bit of logic into configuration files. So your logic is more spread out; some of it is in code, some in config files. The upside is that the configuration can be modified post-build and even post-deployment.

Answer 2

My team did an evaluation of the Microsoft Patterns and Practices Enterprise Library about 2 years ago as part of a re-engineering of our product line. The only part we ended up using was the database block. We even wrapped that in some classes that we could instantiate so we could mock out the DAL for unit testing; the Microsoft code block used static calls for database work. I am not sure if Microsoft has integrated any of the LINQtoSQL or Entity Framework stuff into the db block. I would be hesitant to use the db block now if it did not leverage one of those.

As far as logging goes, we found Log4Net to be a much more robust and flexible solution that the Microsoft logging. We went with that for our logging needs.

For exception handling, we rolled our own. The Microsoft code did not handle the remoting cases we wanted to handle, and since we were using a 3rd party logging framework it made more sense to write our own exception library and integrate with that. I have found that some level of integration of the logging framework into the exception framework can be very useful. We wrote some lightweight wrapper classes around Log4Net and called those from our exception logging so we didn't introduce dependencies on Log4Net.

Answer 3

The choice of not being able to use EF for me is bind by the constraints I have in my environment that requires the applications to process millions of transactions per hour. This is the volume of processing in Telco environment.

Whether to use EF or not is entirely up to your environment and choice (as long as you know the limitations of the chosen technology). If your system does not require such high loads, I don't foresee you will have any problems in using EF.

Answer 4

In addition to the items mentioned by Paul about the data application block I also would like to point out that in my experience the data application block aslo provides a much FASTER way to write the needed database code, with the helpers that exist. I use it for its consistent look/feel and the speed of development.