Have you heard about the "Composite UI Application Block (CAB)" from Microsoft Patterns and Practices? How about the "Smart Client Software Factory (SCSF)"?
They address a gaping hole in the enterprise application development process: how to wire together large applications.
We've got lots of tutorials and sample applications that show how to build a simple screen or solve a single problem. But there is not much available in .NET for assembling the whole enchilada.
It's not like we can avoid the issue. We've all been gluing our apps together in one (unsatisfactory) way or another. I've probably written five separate "application frameworks" in .NET alone. Not because I wanted to. Because there hasn't been an alternative.
Along comes CAB to promise me that I won't have to do that again. Well almost.
CAB combines a tremendous number of solid, established patterns for building large applications as loosely coupled components. On top of CAB there is a "software factory" to help us routinize the application-specific artifacts (especially the application's standard views).
Many find CAB intimidating even when supplemented by SCSF. I was certainly one of that multitude. I'm over the hump now ... and can hardly imagine app development without CAB. Yes, even on small projects.
Now I recognize that these glowing sentiments are possible only because I spent an inordinate amount of time wandering around in the dark, smacking my head on this and that unseen obstacle. There are plenty of us with bruised foreheads and scraped knees. Something has to be done about making CAB/SCSF more accessible ... not just to your average developer (that goal is out of immediate reach) but to your fairly seasoned application architect. I'm working on the education front in my copious spare time.
Is CAB worth it?
I raise a resounding "Yes". I think CAB is transformative technology in much the same way that the shift from procedural to object orientation was transformative.
The "transformation" is not just for geeks. This isn't just another bit of wizardry to learn.
CAB could be most important because it can reduce total life-cycle costs, improve our ability to respond to changing business requirements, make us more productive, and help us shrink the dev team to manageable size. Instead of throwing more bodies at a project (bodies half a world away) we could get the work done close to home - close to the end users who actually understand what we're supposed to build.
CAB could become the basis for a common development culture. Today, each of us is inventing his own application infrastructure - his own private kingdom. Hiring a new developer? You have to show her around the realm; teach her the local dialect, warn her about the trolls over there and the flaming swamp over here. Relax your grip - perhaps to illness, vacation, or insurrection - and your brief reign will not be remembered fondly.
In CAB world everyone speaks the same language. Each of us may have his own idiosyncratic take on the core concepts but at least the major constructs are recognizeable. Show me a CAB app for the first time and I can quickly find North and South, discover the principle landmarks, negotiate its highways.
Murray Gordon (an MS MVP) and I will be talking about all this in a WebCast on April 24, 2007. We're not going to explain CAB - that can't be done in an hour. But we can introduce you to CAB, show you some results, and equip you to explain CAB's potential to management.
Check us out.