Often I get the question 'what is an application block' and 'why that name'? We have lots of articles, webcasts etc describing them how we've built them and how to extend them or build your own. Then people ask 'what is the difference between a block or a library or a framework' and I remind them that we use the Application Block name to reflect a set of expectations around packaging, design and how they could be used.
Using the word “blocks” was done to evoke a set of patterns about how p&p -and hopefully eventually more of MS - chooses to distribute reusable chunks of bits, without constraining them too much a priori. The approach has allowed our team, communities and others to participate in their evolution rather than try to invent something different altogether. There is an existing taxonomy of chunks of reusable code, and using the word "Blocks" was not done to try to introduce a new item in this taxonomy (that would be arrogant) or redefine existing terms.
There's plenty that's been written about code libraries (things you can use), frameworks (things that affect the architecture of your code a bit more), app containers and the likes, so I won't go there. I'll just say why I didn't think this would be a good distinction to revolve around when you are creating names for a new product line.
I believe good names tend to be:
- Unspecific enough that you can accept variability of the named thing.
- Metaphorical. The concept of the name evokes visual, physical/physiological and metabolic actions.
- Associative and work by metonymy, just like 'White House' represents a government, a president, and a big dome, and not a building.
I believe a good name does not need to reflect every detail, or every characteristic, or the complete position in the taxonomy, of the thing it describes. For engineers it causes some heartburn (to realize that better names are not necessarily better for classification) but it's easy to embrace once you understand why.
(If you are interested in this you can read Lakoff or cognitive science papers from the last couple of decades. The one thing that strikes me the most is the impact of physical evolution on the brain's workings, which is one of those conclusions that just strikes me as insightful. What dictates the shape of the box we tend to think in? Thanks Ward for recommending this author)
Back to code. You can read plenty about the distinctions most of the experts in the community put forward between libraries and frameworks. I will oversimplify, but in the end libraries are things I can use, and frameworks tend to mess with the architecture and design of my own code. Maybe containers implementing DI tend to clarify the edges a little bit, by allowing an otherwise hefty-framework-author have better boundaries between what you use and what affects you.
The one difficulty I find when trying to classify blocks in terms of "libraries" of "frameworks" is that folks will not understand application architecture in objective ways. For example, enterprise library is IMO a great example of "Library" chunks. However, if you ask around many folks consider EntLib to 'deeply affect the architecture of their app'. One man's library is another man's framework. On the other hand, CAB has lots of pieces which are canonical "framework" chunks and a gentle sprinkling of "library" pieces. It has both gentle and forceful ways of suggesting a design for some areas of your code. I do think we could have packaged CAB up a bit better by breaking out specific pieces, but we all have constraints.
So to summarize them, the name "Application Block" does not reflect a precise place in the taxonomy of reuse, rather, a loose metaphor that encompasses a family of assets, and how you use them. Using blocks should be a matter of choice, they work together, they can be piled up, you can use many or a few, they will probably have commonality internally and externally as dictated by efficiency and usability, and they should be fun.