Microsoft Enterprise Library

http://msdn.microsoft.com/en-us/library/cc467894.aspx

This is not the first and I doubt the last "application building blocks" resources that I will run across. However, the interesting thing is where it fits into my headspace as a developer.

The  No-resuse model

The application implements all the functionality and essentially re-invents any wheels it needs.

The Framework model

The application uses a domain specific framework that has a pre-built set of infrastructure objects/components which all interact in a way that works but usually requires the application to accept "as-is" and either use in the way it was designed/built or not use.  It's a package deal.   They key point is that the framework is integrated. However, it may do things in a different style or contain some invariats that do not quite fit the problem at hand.  This makes for an awkward fit that may require the application to "avoid" some bits of the framework and use the platform anyway. 

In business this would be considered as horizontal integration and represent a monopoly layer that was common to a number of businesses

The Building Block model

In this model, the application re-uses smaller decoupled units.  These are stand alone components that can be used, avoided or re-invented with much less cost to the application developer. 

There are always tradeoffs, but this allows vertical integration and specialisation without carrying the pros and cons of a whole framework.






I personally find many of the frameworks to be overly heavy solutions for my particular problems. Trying to adapt my problem and solution to the framework is often more work than solving the problem and doing some re-invention.  The cost of the framworks lifecycle, community issues and other "intangible" on your project may be difficult to calculate when you are evaluating a framework as a potential solution for a project. The hidden overheads add to the maintenance cost and the uncertainty, especially with longer term projects.  The value of having a lot of the work already done tends to fall off quite rapidly when your project grows beyone one or two life cycles of the framework.  Especially if the framework evolves in a different direction than you wish to go.  The cost to gut a production system and re-engineer it because a key part of the platform has changed significantly can be ugly.


I feel that the "patterns", "building blocks" and smaller simpler re-use models are the way to go. It's almost back to the Unix philosophy.  (Many small tools that can be assembled to do the job)  It allows the developers to "own" the whole code base, down to the platform layer.  This reduces the long term uncertainty about maintainability of critical components and reduces some of the moving parts in the system.  I like this.