Is CAB complex? And if so, Why?


 


Recently, there have been several posts critical of CABs complexity. Personally I have no issue with being critical of the complexity of CAB. First off, it’s your right to give your opinion. Second, CAB is complex! Whether that complexity is warranted or not is open to debate. One of the reasons we built the Smart Client Software Factory was to make CAB more approachable. The way SCSF does this is through automated guidiance (recipes) that help you build some of the core CAB components such as a Shell, Modules, Views, etc. Without SCSF, building on CAB is significantly more difficult (though not impossible).

Most of our customers have said that the learning curve is significantly less when you use SCSF. You don’t start off with a clean slate, but with a working application. Furthermore the guidance packages provide assistance as you further develop out your application. Now is it an end all solution? NO, but it certainly makes working with CAB dramatically easier, at least per our customers’ have told us.

As far as the complexity of CAB itself, let me first clarify one thing. SCSF / CAB is by no means meant to replace standard Windows application development. On the contrary, CAB was built to address some very specific requirements based on very real applications. These include the Microsoft Customer Care Framework and the Integrated Dell Desktop. The requirements of these apps are:


  • Ability to support multiple teams developing different parts (modules) in isolation.

  • Ability to extend existing and add new modules to the application without recompilation.

  • Loosely coupled components that can share data and interact with one another as well as the UI (i.e. populate menus, toolbars, and status bars) 

  • Standardized and extensible layouts.

  • Pluggable UI components.

  • Pluggable application services that can be globally accessable such as Authorization and Authentication.

  • Separation of UI, Business and Infrastructure concerns.

  • UI Testability.

  • Reducation of repetitive coding tasks.

  • Simplified deployment.

CAB provides a standardized, repeatable approach to addressing all of these concerns. However these benefits come at a cost one of which is complexity. That being said the compexity CAB introduces is far less than the complexity one would face if they were to build the same functionality from scratch. Now if you don’t need this functionality within your app then CAB can certainly be overkill and can make your life far more difficult than building a simple windows application. The other side to this is that using CAB is not necessarily an ‘all or nothing’ game. For example if you wanted to, you could have one Shell project and only use CAB for the UI capabilities such as Workspaces and Smart Parts. CAB does not require you to define WorkItems, Services, etc.

As to our implementation of CAB and using ObjectBuilder, etc, it gets the job done. Now could we have done better? I am sure we could have. Is CAB perfect? No. Did we say it was perfect? No. We do know that many of our top tier customers love CAB, and are using it in some very large mission critical applications. The adoption of CAB continues and with SCSF, developing with CAB is more palatable. This is what we hear from customers.

Just the other week I spoke with a customer about a large scale migration they performed to CAB. One benefit they found was a significant reduction in the original codebase once they got to CAB. The other was the common taxonomy CAB introduced within their orgranization which helped bring all the developers and architects on the same page. Once the basic CAB concepts were absorbed they reached a phenonmenal level of efficiency. I can’t tell you who the customer is, but you will have to take my word for it.

Lessons Learned

When we set off to develop WCSF we had the aim of providing a more simplified model (based on customer feedback). In developing CWAB we deliberately dropped a lot of functionality that had been present in CAB. Since then our approach in WCSF has been to add features solely based on what our customers are asking for. We’ve been very transparent about both our plans and the actual development and will continue to do so. For our last release of SCSF we had community drops every two weeks which we are planning for the next version of WCSF as well.

patterns and practices:

I’ve heard a lot of comments about patterns and practices, how we don’t care abut customers, are not connected, etc. As many of you know I only recently joined patterns and practices as the Client UIX Product Planner. What I can tell you is that connecting with customers is priority number one.

1. In the first month alone, I have engaged with 10+ customers. In at least 4 of these cases, this was customers who came on site for several days and engaged 1 on 1 with the team. This included our product planners, program managers, architects, and developers. The customer list is a mix bag of both those who have already built on our deliverables as well as those who are looking to use them in future projects. They sizes of these orgs varies from small ISVs to medium and large enterprises.

2. All of our our product plans are reviewed by an advisory board comprised of industry professionals that are actually using Entlib, WSSF, WCSF and SCSF within their organizations.

3. We regularly gather customer feedback through Codeplex WorkItems, Surveys (we recently launched an factory surveys), blogs (all the product planners and much of the p&p team have blogs), web casts, and direct emails. Personally I have posted several times in the last month alone asking both implicitly and explicitly, ‘What do you want us to build?’.

4. We recently worked with the community to launch a set of contrib sites for providing community extensions which ultimately will aid our customers.

This is not to say that we are perfect and that there aren’t areas we can improve. We can. We are always open to your suggestions, so if you have any for WCSF / SCSF, please contact me directly.






Share this post : del.icio.us it!
digg it!
live it!

Comments (34)

  1. .NET Geek says:

    It’s been a busy week in the CAB/SCSF corner of the blogoshpere. I guess it all started with Oren’s post

  2. Bil Simser says:

    Any chance of opening up the source for the customer care framework application? It might help people see a "real" application using CAB and help drive better CAB adoption with real world examples rather than QuickStarts and samples.

  3. Pieter says:

    I love CAB, and yes it is more complex than a standard winforms app, but the learning curve is worth it.  There is also a lot of info on the web today, which makes learning it so much easier.  I learned CAB when there was almost no way to learn it other than looking at the quickstart samples, so all I will say to those whining abaout its complexity is to get stuck into it and when you get that aha moment you will understand just what CAB can mean for you when developing applications.  My main attraction to it at the moment is the ease with which we can extend it and all the applications we support without doing major work on our code base.  Well done P&P team.  Keep it up.

  4. On tools, CAB and EJB

  5. John Rusk says:

    >All of our our product plans are reviewed by an advisory board comprised of industry professionals that are actually using Entlib, WSSF, WCSF and SCSF within their organizations

    What about review by some people who are _not_ using it?  Choosing reviewers from existing users will result in a somewhat "biased" sample.  (Biased towards those who are tolerant of the products’ complexity and other alleged flaws).  

    Why not get some input from people who have chosen not to use these products – what don’t they like?  Is there anything to be learned from their reasons for chosing not to use these tools?

  6. gblock says:

    Thanks John

    We actually have both people that are using it, and people that are not (but looking into it) about using it on our advisory board. All of our plans of what we are building are shared with the community as well. Feedback is welcome from those who use it and don’t use it alike. This is the exact reason why I posted my "What would have us build post?"

  7. Boris Drajer says:

    I’ve been using CAB for a year now (built my company’s application framework from scratch on top of CAB), and to me it’s by far the most useful piece the P&P bunch has released so far. And I’m talking about CAB without SCSF… The SCSF part dictates an architecture that isn’t entirely compatible with what I had in mind, and seems to impose some development overhead because it isn’t entirely friendly to form designers.

    I agree that CAB is complex, but necessarily so because it covers a lot of ground. What augments its percieved complexity – and annoys the hell out of me – is the fact that it’s been almost a year and a half since CAB’s first release and we have no decent documentation other than an API reference and ten hands-on labs. I still don’t know the full details on how CAB is supposed to be implemented. So it’s a small wonder that people who can’t invest much time into evaluating CAB find it daunting. And because it’s bigger than other DI frameworks, even for the people who understand DI it’s hard to analyze more than a small part of CAB’s source (as this is the only good way to learn it) so they tend to dismiss the rest of it as bloatware. At least this is how it looks to me… So, in summary: document the darned thing already: give us a class-by-class explanation of what it is and how it’s supposed to be used. And then ask me what I want to see in v2.0, because I have some ideas 😉

  8. Some One says:

    I like CAB but at the same time it is too complex. One needs to keep in mind that a team of people work to write code. One person my understand the complexity but the majority wont. I just got done re-writing a recursive logic to stack iteration because of complexity. Not becasue it was slow or ineffeciant it was buggy. On top of that for others to debug it was to difficult figuring out parent child inheritance. Changed to stack iteration and the issue of complexity and debugging are gone.

    Then like others have said lack of documentation or a real application using it. Luckly I have a Infragistics License and was able to get more info from that http://www.infragistics.com/hot/cab.aspx

    So with complexity in of itself and lack of document it is used by some, but like my recursive logic if something goes wrong it is too complex to understand and troubleshoot. Then not to have good documentation and a real application to reverse engineer it turns CAB into goo.

    What I did for my team was learn from it and build a specific framerwork for us without the complexity. Is the complexity there to meat the masses? In order to do that one must make a complex system? Our simple soultion is not that complex but it might not work for others either.

    On thing also with complexity. I believe there are to kinds. One like my recursive logic where it is confined to maybe a method or two but all in one class file. But during execution and deubgging and trying to follow the execution pointer, and where you are at in the looping logic, and if the method is on the first or hunderedth cycle. Complexity in run time. Then the other is like CAB. I have one class file open but I need to go to a decleration of some object, or the base class this class is derived from. This is in another file and then another and yet another. Then when I get where I’m going and find the right class file, I forget what I was doing. Spent to much time trying to figure it out. Again this is where a real world sample comes in. I could say well how is done with this application. Also CAB has the run time complexity during run time and debugging I see the execution going through many methods and class library before I see any of my code run.

    Finaly I don’t think it is MS CAB that is complex, the concept is complex in of it self. I believe the concepts of MVP or MVC needs to be grounded with the programmers before starting. And maybe some GOF patterns relating to command meditor and watchers, the service concepts, also some unit testing and mock set ups.

  9. gblock says:

    Some one and Boris, thanks for your feedback, and I feel your pain. I’m going to look into the documentation issue and see what we can do.

  10. Some One says:

    Another thing which is common with MS that makes it complex or confusing is the over use of Acronyms and assuming everyone knows them. The funny thing was while I was writing my previouse post I was thinking I know what CAB is (and not the file format confused?) but I don’t know what C.A.B is. I know what a file with a .cab extension is? Just felt a bit wierd talking about something I know when I don’t know what the acronym is.

    CAB Composite User Interface Application Block

    SCSF Smart Client Software Factory

    WCSF Web Client Software Factory

    WSSF Web Service Software Factory

    Is there a way to send these over to the department that came up with names for Expression Studio to come up with a name for these and use a single word like Blend, Web, Design, Media? And stop using ancronyms.

    Call it something anything or send these over to the code naming masters that gave a project a name like Longhorn. Not only that saying something like fancy-word is easier than SCSF or WSSF. By the way how are those acronyms pronounced? At times just trying to explain to a progammer what it does is hard when trying to us WSSF or SCSF in a spoken sentance. Luckly for us CAB worked out to be a word, is that pronounced like a yellow cab or taxi?

  11. Some One says:

    Thank You,

    – Guy

  12. TRAN Ngoc Van says:

    I’ve been trying to use CAB from the very first releases of CAB. But until now, I still cant use CAB for my projects.

    At one point, I dont know what should I do to achieve this, how to do that.

    For a button, to change its layout, check out its properties. To handle events, check out event tab of property grid.

    But for CAB, it’s not that simple. There’re lots of methods, function. I used to do this but I should do that to comply with CAB, etc…

    I think the most important thing that concerns new CAB users is CAB document. Please some document for us, dummies.

    I’ve seen you do this, do that. I’ve seen how wonderful CAB are, but please teach me how to do.

  13. So over the past week, I’ve been following a bit of a stirring the blogosphere over the deliverables

  14. There’s been two great posts on the CAB debate recently that were interesting. Jeremy Miller had an excellent

  15. The Big Orange Heads says:

    Having participated in one of the recent customer feedback sessions can I just say in support of Glenn what a beneficial experience it was.  

    It certainly allowed us to get a very good view on ent lib deliverables and come up with some ideas of direction that we want to go in.  Hopefully we also provided some useful information the other way.

    Also the SCSF has gone a long way to helping with the complexity of CAB.  We were initially very concerned about the complexity of CAB and SCSF has allayed some of these concerns by making it much simpler to develop.

  16. Boris Drajer says:

    Thanks for your answer, Glenn! Yes, I forgot about the Raiffeisen example, it does make the broad picture a bit clearer. Unfortunately I found it only after I’d gotten the hang of CAB so I admit I never gave it that much attention… But even with it a lot of detail and some whole sections (like the ObjectBuilder API) are missing in what documents there are. I’ve been looking again at CAB documentation and tried to remember what troubled me the most: well, for one thing, there’s no real introduction. It starts shooting bullet lists 😉 and diagrams immediately with very brief explanations. It really needs to be much more readable (or point to some introductory text suitable for absolute beginners). One has to deduce the logic from working examples which is very hard.

    As for the details, I think that just upgrading the existing help to MSDN standards should make things easier (currently, most of the classes and members have just a one-sentence description). I’ll give you an example: what does WorkItemTypeCatalogService do? It is only briefly mentioned in the documentation and never explained. There’s even a walkthrough that shows you how to use it but never says what it does. You have to google for it and even then the best explanation is John Luif’s blog post from the CTP2 days. If I needed something this class provides I would have never found it because I’m not subscribed to John’s blog ;).

    Don’t get me wrong: documentation is just part of the solution, a way to make the task of climbing the CAB-hill (and it is a hill, not a mountain) easier. General public should beware that CAB is not just a "utility library" like the other application blocks (or some DI alternatives, for that matter: this is why I like CAB more). Moving to dependency injection is similar to moving from procedural to object-oriented. On the other hand, CAB’s nowhere nearly as big and complicated as, say, ASP.Net, so there’s no justification for too much whining either :).

  17. Paul says:

    Are there any published applications that require developers to implement a CAB module in order to extend the main shell, add functionality, or extend a published module?  It would seem that CAB is perfect for writing plug-ins (like for office applications).  I believe if it was less complicated, you would see many applications using CAB for the plug-in arch.  I don’t know of any public applications outside of MS that use it.

  18. Andrew says:

    We are looking at CAB for a large customer project, for which it fits really well.

    One concern however is the whether or not CAB has a future, with respect to the noises coming out about Acropolis?

    The comments so far indicate a great deal of learning investment over CAB.. will this be wasted if Microsoft branch off in a different direction for Smart Client?

  19. PandaWood says:

    >>What about review by some people who are _not_ using it? … Choosing reviewers from existing users will result in a somewhat "biased" sample.

    This logic here is pretty funny… Why don’t you get people who don’t see a movie to review it? After all, you don’t want actually seeing the movie to bias your review.

    I can take the point though 😉 However it would be extremely difficult to find people who actively don’t use it, to spend time giving input. And the quality of input would vary wildly depending on how much time they had invested into learning it.

    Point #3 in this blog would seem to cater for what you’re talking about anyway.

  20. DickP says:

    I have been looking at SCSF this week and I thought I would report my experience.

    I am not an experienced UI developer. I am developing the smartclient for my ERP solution. It is now getting unmanageable so I was attracted to SCSF to bring order. SCSF seems to address many of the problems I am facing.

    After looking at SCSF for several days I don’t feel I fully understand it. I am reluctant to to implement it on my app because it might destroy productivity. I get the basic concepts, but I don’t really understand how all the bits hang together.

    The documentation is inadequate. Part of the problem is that SCSF introduces it’s own vocabulary so that after a few paragraphs the documentation becomes a cacophony of noise.

    SCSF is supposed to make CAB more useable. Unfortunately the effect is to compound the complexity and confusion.

    If you are willing and able to stick with it no doubt the penny does drop eventually. Having said that, the few posts I have read indicate that even those who are using SCSF/CAB are not totally sure they are using them correctly, or fully.

    SCSF/CAB are complex, but so are many things. The .net class libary is complex. I would go so far as to say that the current package is user aggressive. I cannot say if the problem is simply a lack of information, or if the overall approach is fundamentally deficient.

  21. Chandra says:

    I recently started reading CAB. I found the CAB interesting but complex to understand. Initially I read the documentation with lot of enthusism but gradually faded away. I am still reading the documentation after 2 days and still not confident that I will be able to use CAB in my projects. I feel the samples are not implemented in a consistent way which makes the CAB hader to understand.

  22. gblock says:

    Hi Chandra

    Did you look at the Smart Client Software Factory. SCSF builds on top of CAB but facilitates building a CAB application. Also there is more extensive docs within SmartClient in addition to several QuickStarts, and a Reference implementation that brings it all together.

    If you have more questions, email me at gblock@microsoft.com

  23. In the wake of the "great debate" over the complexity of CAB, Jeremy Miller has done a series of posts

  24. Ok, I’ve been using CAB, the SCSF, in "pseudo kinda sort of" Model View Presenter Pattern usage. …

  25. Hi

    all this not it is correct , it is correct only that

    [url=http://alls-rars.ueuo.com/jeep-4×4-part]jeep 4×4 part[/url]

    G’night

  26. xivoz says:

    <a href=" http://clothing-2-df3.110mb.com/ ">Soldiers for christ clothing</a>

  27. oiicy says:

    <a href=" http://school-ut3.0catch.com/ ">Bible high school literature</a>

  28. Some time ago we announced that patterns &amp; practices was going to be delivering a new set of guidance

  29. Some time ago we announced that patterns &amp; practices was going to be delivering a new set of guidance

  30. Glenn Block says:

    Some time ago we announced that patterns &amp; practices was going to be delivering a new set of guidance

  31. Before I go any further, we shipped! :-) Links: Composite Application Guidance Landing Page (will be

  32. Glenn Block says:

    Before I go any further, we shipped! :-) Links: Composite Application Guidance Landing Page (will be

  33. Before I go any further, we shipped! :-) Links: Composite Application Guidance Landing Page (will be