What are the limitations of using ApplicationBlocks (An Introduction and Overview of the Microsoft Application Blocks) for ASP.NET/VB.NET applications? I have found lots of websites that talk about the benefits e.g. divorcing the data tier from the web tier, but I cannot find a web page that discusses the limitations.
1 Answers
I don't think you can really get a plain list of disadvantages. Microsoft Enterprise Library is a good library, well documented, rich and with tons of features.
You should change your question to "When I do not need to use it?". Of course this question should be repeated for each block. I'll try to summarize a little bit.
For every block you should consider to do not use the library when you do not need its complexity. Features doesn't come without a cost and the most obvious one is complexity (first in deploying and configuration). If you have to document and your user have to change application's configuration you may need to provide some tool or a lot of documentation. Complexity can be hidden in code too, even if EL designers tried to make everything easy it can't be as easy as a raw solution.
Second important disadvantage is obviously the speed. Layers of abstraction can't be for free and you'll pay a speed cost for that. In some cases you may do not care (simple Logging, for example) but it may be a problem in other cases (so again the answer is "it depends"). Think, for example, to Unity Application Block: you'll get all the power of injection but you'll pay a great cost for this.
So when you should use it? In my opinion a big goal of this library is that you do not need to use it all together. You can pick blocks you need when you need them. It's very common, for example, to use Logging and Exception Handling but you may not need Unity in whole your life. The Data Access Application Block is a very thin layer above ADO, it simplifies many common tasks but you do not gain the level of abstraction you have, for example, with LINQ to SQL or Entities (hey, do not forget they have very different purposes) and you should consider to use it only if everything else can't suit what you need.
So, finally, in my opinion you should consider each block and use it only and only if you really need all the complexity that comes with an Enterprise level library. It's not designed for small single user applications (even if sometimes you may find that some Application Blocks may be great for a specific task). Its drawbacks aren't little: complexity and speed can't be ignored (both for short term solution and long term maintenance plans). Moreover if you really need all its power you'll find it's not as easy as a "ready-to-go" solution, to have the control you'll need to write more code.

- 65,416
- 20
- 137
- 208
-
Do you have any production experience of using these blocks? What were the issues? If you just give a couple, we could assess their severity and make a pretty much non-biased decision if they are good or not, and why. – Victor Zakharov Oct 17 '12 at 20:22
-
1@Neolisk yes, I did use (and I still use when needed) most of them (Exceptions, Validation and Caching pretty often, Unity and Security just sometimes). I did stop to use DAC 'cause usually I don't need it (as I said higher levels libraries are enough for me and when I have to go down to lower level it's always for simple tasks where I do not need DAC). My point about this is (for w0051977): ask yourself if you need what you'll get, if answer is just "wow, it's cool" usually you won't be repaid enough. – Adriano Repetti Oct 17 '12 at 20:44
-
I am trying to separate concerns with a data access layer. I thought application blocks would be ideal. – w0051977 Oct 17 '12 at 21:55
-
@w0051977 it depends what kind of business model you'll use. With Entities or another ORM probably you won't need DAC. Its purpose is to abstract physical database details you if work directly with connections, commands, readers and so on. (but you may find useful Exceptions AB to build a solid wall around each layer). – Adriano Repetti Oct 18 '12 at 07:13