To CAB or not to CAB

Topics: CAB & Smart Client Software Factory
Mar 15, 2006 at 5:24 AM
originally posted by: timnelson

I've been working with CAB for the past few weeks as my company plans on building a development framework for .Net. I have suggested CAB would be a great solution for this since most of the requirements we've outlined are already implemented by the CAB. The competing opinions (that have only skimmed through CAB), say it's not worth the trouble and we could implement the parts of the framework in a couple of months! (Assuming we may need 50-75% of what CAB provides) I have countered that this is a huge piece of work written by seasoned .Net guys (we've got only a couple of them on the team) and it will take a lot longer than that. I'd be interested in anyones opinion on this as I really don't want us wasting time re-inventing the wheel when there is a nice one already here for us :-)
Mar 15, 2006 at 8:01 AM
originally posted by: jbarmash

Well, CAB does take a while to understand and get used to, but reinventing it sounds like an overkill - i can't believe that developing your own framework will be faster, plus people will have to learn that anyway.

What I have seen some people do is for the architects to build a layer between CAB and the developers, so the developers don't really need to know much about CAB. More specifically, I am talking about building your own module, view and controller classes that all your developers would be subclassing. Put something like Add command to the CAB module, so they can add smart parts there, and you are good to go - all the other stuff - the shell, etc, can be handled by the architects.

Additionally, I've seen projects pick and choose different parts of CAB framework that made sense for them. For example, they didn't use commands infrastructure, used the eventing instead because it fit their needs better.

Pre-CAB i've also seen a bunch of guys build their own frameworks, and even though they solve their problems, CAB at the end of the day is more comprehensive, plus completely EXTENSIBLE - you have the source, so why not take it and customize for your needs?

Mar 16, 2006 at 8:19 AM
originally posted by: ManagedCode

I agree with Jean. As an Architect on an Agile team that is employing CAB, we found that CAB provided a lot of value in many areas and it would have taken much longer to implement than the time specified and would still not have neccessarily reflect best practices. What I have found is the early complexity of CAB overwlemes people. The new GAT Guidance packages with SCBAT help with that.
Mar 17, 2006 at 8:56 AM
originally posted by: GilY

I also agree with Jean. Consider your alternative to CAB. Imagine you build YOF ("your own framework"). Note: You did not have to develop CAB, but you do have to develop YOF. There is no community for YOF, no blogs, Hands on labs, Quickstarts, consulting companies, or trainer for YOF. There will never be any type of "support" (e.g. a GAT recipe, perhaps a design surface, etc.) in VS for YOF (unless you build it). And there will never be a webcast you can share with your developers on YOF (unless you produce it yourself). You probably won't get the funding Microsoft will get to make sure YOF will work with WCF, WPF, etc. If you screw up the code -- point the finger at yourself. If an app using YOF fails in production, you are the only person who can help you. That is a risk your company should not take. If you leave, they are screwed. You might be a brilliant programmer -- but consider the team of people who built CAB -- meet them, spend a few days with them, and you'll be humbled. If indeed you can build a better YOF than CAB -- you should be quite famous by now. Sorry for the "hard sell". But CAB is certainly better than the nothing you have now.

That said: CAB is not simple! I believe that your average developers will need training in CAB. I have asked the community about training here: (also

And I brought both David Platt and Infusion to train CAB for developers in my company -- both were very worthwhile -- we got over 30 developers trained in CAB. It was worth the time and money -- I don't want to use this space to advertise for them -- if you have questions email me directly (via the GDN link to the left) and I'll respond directly. (I'm just a happy customer, not an agent.)

I just attended the 2.5 day SC-BAT workshop -- this confirmed for me CAB, even with SCBAT, is not easy at all. So the lead architects need to grok CAB and SCBAT, and then learn how to develop GAT recipes. Read Sam's comment:

Success with CAB and SCBAT is more about GAT than you might think.

Suggestion: assume that the average developer will have a learning curve with CAB. Get 2-3 days training (at a minimum). Force them to do the Hands on Labs (slowly and methodically -- in groups). Also you may want to get a consulting partner to pair up with on the first (few) projects. The money you saved by not building YOF should be invested in making CAB work for you. As you develop "best practices" for how to use CAB in your environment -- bake those best practices into GAT!! -- and then give the GAT packages to your developers (so they can focus on the application logic, not the CAB goo).

Again, I think there is a real learning curve, but once you are past it, you will find CAB to be worth the investment of time (and a much better experience than building, debugging, and training others in YOF).

Mar 17, 2006 at 1:58 PM
originally posted by: ChrisHolmes

I'm just going to echo the sentiments already posted here: CAB is the way to go. Building this sort of infrastructure yourself is not going to be quick or easy. What the CAB costs you in initial time spent on the learning curve it will save you later when you understand it and can apply it.

I really can't imagine wanting to build this sort of thing when it already exists. Once you understand the CAB it's very easy to work with and you can quickly get things done.

I'll have to check out the GAT too. I've been working with the CAB without any help other than the docs and my noggin'. There's a multitude of ways to solve problems with the CAB and sometimes it can take a while to figure out the "best" way to do something. It will be interesting to me to see how close my own design practices with CAB are to the recommended best practices from the GAT.
Mar 18, 2006 at 7:03 AM
originally posted by: jbarmash

One more point - say you make the decision to write your own framework. Say you do a great job and reimplement a lot of the concepts from CAB (which are generally the concepts you need to build composite clients). Your developers are still going to have to spend time to learning it and bring back to you any issues they find.

So to save time learning CAB and customizing it for your needs, you spend more time implementing your own framework (which I will grant may serve your particular needs better out of the box), then preparing documentation / training for it, training your developers in it, and supporting it. On the plus side, this does lead to better job security :-).

Happy St. Patrick's Day!