There's yet another (worthy) discussion going on in the altdotnet list about whether or not to choose CAB, another framework, or roll your own framework for a given desktop client (I'm saying desktop client here because I'm thinking of the superset of either WinForms or WPF regardless if they're "smart" clients). Maybe first, we need to answer the question "do I need a framework at all?" When I tell people that I don't recommend the CAB a common response is a fear that it'll take too long to write their own framework. I think your first course of action is to determine what you really need and go from there.
This quote from Steven Mitcham set me off a little bit (emphasis mine):
Speaking from a position of having to support a hand-built framework that was not engineered with the best practices, you need to be certain that your project management and/or customer is going to support the overhead of a constant stream of "It wasn't really designed for that, so we'll have to make this breaking change" type interactions, if you aren't going to go with an established framework.
Let's think about this for a second. What's the root cause for answering with "the framework wasn't really designed for that" to the question "can we do this simple seeming thing in this screen?" In my experience this scenario plays out because you're using an abstraction that's optimized for too specific of a scenario. The usual cause is falling victim to architect hubris and framework fool's gold by trying to create an uber-abstraction too early. Other times it's caused by trying to reuse an existing framework that's optimized for different usages than what you have on your plate. When you build an abstraction that tries to do almost everything for you, you can generally only do the things that the abstraction means for you to do. You've made yourself faster in the specific case, but probably slower for every other single scenario. If a framework tries to be more flexible and accommodate more cases, it probably strays into being too abstract and too generalized. When you find yourself spending too much time with artificial concerns like WorkItem's and ModuleItems and whatnot, are you really getting anything out of the abstraction? There is power in abstractions when they fit and there is pain when they don't.
I don't care for some specific elements of the CAB (ObjectBuilder, the event aggregation approach, the Module bootstrapping is clumsy IMHO), but the biggest issue for me in choosing NOT to use the CAB is that it wasn't designed specifically for my application. It's built for generic scenarios. Least common denominator approaches and structures. My contention all along has been that I can gain more value from creating the abstractions in the application that fit my needs. That being said, you need to be very careful with these abstractions to be something that does add value. For best results, you need to avoid leaky abstractions and wait until the last responsible moment. If you try to build a framework before doing the application, use an existing framework like the CAB, or use somebody's software factory*, you are automatically choosing an abstraction early. You might be breaking on a decision before the Last Responsible Moment. Your chances of screwing up are much higher than they would be if you were responsibly harvesting abstractions as the application needs to remove duplication. If you have to wrap your design around a tool, the bar for using that tool is far higher than it would be for a simple library like log4net.
My advice? Use frameworks very, very cautiously. I don't, haven't, and won't, build my own CAB because I don't think there's any one or even a few abstractions that are generally applicable across applications. I don't need everything in one app, and each app is different in crucial details.
Keep the complexity to a bare minimum. Using or building any framework automatically accelerates you to the inherent complexity of the framework. Make every abstraction in your system earn its right to exist.
It's far more valuable to learn the patterns, including the "why' behind the pattern, and build your own structure to support the exact needs of your application. Go look at other people's frameworks, but don't assume that it'll work for you right off the bat.
* I'm getting very interested in using microgeneration, ReSharper/CodeRush templates, and more IDE automation to improve productivity. That part of Software Factories looks cool. My fear is that Software Factories are being used to dress up BDUF in more attractive clothing. Worse to me is the fallacy that you'll be able to create a good design with crappy developers by using a tool to constrain the developers. I think the success of software factories is going to be ultimately dictated by how easy it is to customize and evolve the factory -- which seems to fly in the face of the software factory goal of industrializing software development.
Posted
01-09-2008 5:43 PM
by
Jeremy D. Miller