Meanwhile, there were many unanswered questions and comments of such general interest that I thought I'd respond here.
Q: The webinar addressed two distinct audiences - managers and architects - but it seemed to speak mostly to the manager. I'm an architect who recommends to management; I think it might have been better if you spoke more to the architect.
A: That's a great observation and a dilemma we suffered through. Although the webinar announcement clearly target the manager, promising to make the business case for CAB, we knew that most of the initial audience members would be architects.
In this webinar, we were trying to prepare architects to explain the business import of CAB to management. Architects tend to be good at speaking to each other - and not so hot at communicating with management. We hoped to arm the architect with material that managers could understand and find persuasive.
It isn't that managers are stupid. Rather, they are accustomed to technical staff proclaiming the "next great thing" without any business rational. They've heard too many hasty and unsubstantiated "better, cheaper, faster" arguments backed by incomprehensible techno-babble.
We made the "better, cheaper, faster" case to be sure. We hope we did so in a cogent fashion, supported by value points in CAB. We tried to explain the tangible substance of CAB - going beyond the marketecture - without dropping into the withering detail that architects crave and manager detest. We hope we made a case you can use with your management - one that speaks to their concerns without talking down.
We did not expect we could fully persuade the architect of CAB's merits; that's a project for another day. On the other hand, we tried to include enough developer meat to persuade the architect that CAB is worth a deeper look.
Q: What is the difference between SCSF and CAB?
A: I don't think we were as clear about this as we could have been. Let me try again.
CAB is an architectural layer for building composite applications with a user interface - with a "client" of some kind. That client could be a smart client, web client, or mobile client and each of these client types can be implemented with different UI technology. CAB is a foundation for building all of them.
You can think of SCSF - The Smart Client Software Factory - as a layer on top of CAB. While CAB is for any client application, SCSF targets "smart clients" in particular. There are parallel "software factories" - Web Client, Mobile Client - that target other client types.
The other key difference is that CAB is just code while SCSF is a "software factory".
Code is something you can take and use. A "software factory" has loftier goals. It provides not just code but all kinds of artifacts (e.g., documentation). Moreover, many of these artifacts are generated on-the-fly according to "recipes" devised by application architects (people like you and me). Executing recipes typically present a wizard; the developer answers the wizard questions and the recipe generates the artifacts.
The application architect can build his or her own recipes and, thereby, direct the development process, guiding application development along well-prepared paths that promise the speed and quality characteristics we expect of a "factory" process.
One final - and crucial - point: you can use CAB without SCSF; you cannot use SCSF without CAB.
Q: Can you recommend something to read about CAB/SCSF?
A: We took a stab at this in the webinar. It's not as easy to read about CAB as it should be. For the most part, you have to poke around in many places and cobble together your own training course.
The place to start is the Microsoft Patterns and Practices site: http://www.codeplex.com/smartclient.
Take the time to read the help files for both CAB and SCSF. I like help files (.chm files) for getting an answer to a question but I prefer reading the printed word if I'm going to cover a large subject. One of our clients printed and bound the CAB help files ... and I am supremely grateful. I suggest you take the time to do the same.
The best whitepaper to my knowledge is Mario Szpuszta's Raiffeisen Bank whitepaper.
David Platt is writing a book, due this summer, and is touring the country with his seminars. I have not been to one myself but I know someone who has and he thought is was very good. I read a few of the page's from David's handouts and they looked darn good to me as well.
There was an article about CAB in the September 2006 issue of MSDN magazine. Be advised: this is not a good introduction to CAB. I found it impenetrable when I first read it; it makes much more sense to me now. Read it after you have a little experience.
At my company, IdeaBlade, we are promoting "The Cabana Project" as a vehicle to learn CAB. It consists of a reference application, training classes, and training materials that show you how to marry CAB and our DevForce product. We're light on the explanatory materials at the moment but that will be changing shortly. Check it out.
The SCSF and CAB "hands-on labs" and reference applications are not "literature" by any means but they are a viable way to explore and learn. Note that the SCSF examples were developed after the CAB examples and reflect some important changes to the preferred patterns. In particular, SCSF recommends MVP over MVC and the use of a WorkItemController instead of subclassing the WorkItem; I strongly agree with these changes.
Which brings me to observe that there are many divergent opinions on the "best way" to build CAB/SCSF applications ... mine among them. Frankly, I have yet to find anyone who understands real world MVP ... except me (ha ha)
Q: Is the Cabana version demonstrated in the webinar available for downloading?
A: You can get it from our "The Cabana Project" web page. I am about to update that code this weekend to reflect my latest thinking ... and will follow with a VB version soon after. Go there now if you can't wait.
Q: It doesn't seem that Cabana uses the Windows Forms designer for building the views; is this a CAB restriction?
A: Briefly and emphatically: "No, you can use the visual designers just fine in CAB and SCSF."
Clearly I have some explaining to do - explaining that is outside the scope of this particular blog entry.
In fact, I use the visual designers a lot when it comes to laying out simple "form" views. But, as you may know from some of my other writing, I don't use them at all for grids and it is important to understand how to construct "form" views entirely in code if your application will change the appearance, behavior, or visibility of the widgets on screen at runtime. Cabana demonstrates the role of the presenter in such scenarios.
You may also be highlighting another design preference of mine that gets strong play in Cabana: building by composition. What appears to the user as a single page is actually composed from many individual views, all instantiated, assembled, and coordinated by a "page controller". We talked about this a bit in the webinar and we discuss (and demo) it at length in our CAB classes.
Look for more on this subject in my upcoming CAB video series.
Q: How does the Infragistics CAB Extensibility Kit fit in if you are building apps with CAB and IdeaBlade? How about Developer Express and other third party control suites?
A: Infragistics has been a leader in its support for CAB. For example, they've done a great job of wrapping their UI container controls so that CAB applications can use them as CAB "Workspaces". They wrapped their menus and toolbars for use in CAB "UIExtensionSites". They re-wrote some of the CAB reference apps to demonstrate how to use their controls in a CAB application. And they've provided some instructional materials to help you get going. Check them out.
Espen Schaathun has been doing the same thing for Developer Express controls. I don't think Espen works for Dev Ex; this looks like another contribution from an angel in the CAB community.
Both Infragistics and Dev Ex CAB "extension kits" work fine with our IdeaBlade DevForce product by the way. Contact us to learn more about that.
I don't know what other UI control vendors are doing to support CAB.
Q: Do you have a login module, with users and roles?
A: IdeaBlade offers several login examples suitable for 2-tier and n-tier applications all of which work with CAB. There are two in Cabana if I remember correctly. None of them do anything with roles.
Murray (my co-anchor on the webinar) expressed some thoughts on this topic in the Q&A section of the webinar; you might want to contact him to learn about his experience.
It isn't hard to capture and forward roles. They fit neatly into the .NET IPrinciple interface that we support. We just haven't gotten around to demonstrating how to do it.
It is somewhat harder to settle upon the way you will use roles in your application. This topic is out of scope for today's blog (follow up with me later).
I must add that CAB provides native support for selectively adding and removing modules based on user role. The SCSF "Action Catalog" offers an answer to the question "how should I make my business logic conditional upon user role?" You may want to explore these topics in the help and reference apps.
Q: I have heard of MVC and MVP; what is that all about how would that matter to me?
A: Murray and I agree that Model-View-Presenter
I can't cover the pattern here; I'm going to do a presentation on it some time next month. And if you ask the question this way, don't worry about what MVC is or how it differs from MVP; the distinction is more useful to historians than practitioners.
For now, I'll leave you with these thoughts.
- The most important aspect of the pattern is the separation of your business object
(M)odel from the "presentation" which is represented by(V)iew and(P)resenter . Do this even if you never separate(V) from(P) . - Separation of
(V)iew from(P)resenter translates to a separation of visual layout components (the view) from the supporting non-visual code (the presenter). Yes, I'm oversimplifing but, as Jack Nicholson (sort of) said, you aren't ready for the "truth". - Do this in order to
- Identify, isolate, and consolidate the behavior that is common to many or all of your views. Such abstraction and consequent refactoring is all but impossible until you physically separate the idiosyncratic visual material from the hidden logic that the views obscure.
- Test your UI. It is notoriously difficult and expensive to test the application user interface so almost no one does. Acknowledge this fact and deal with it. Deal with it by pulling out the non-visual logic into a separate class that you can test. Keep pulling until you've left behind in the visual class (the view) whatever it is that you can no longer afford to test.
- Prepare for migration to different visual technology. This could be as simple as a change of UI control suites. I'm able to switch from .NET to 3rd party controls in my "view" classes rather easily without altering the non-visual, "presenter" classes. Moving to WPF will be harder; but this step - separating visual from non-visual - will make that transition easier than it otherwise would be. The same goes for re-imagining your application as a web or mobile client.
Q: Has anyone heard any word on a VB version soon (or at all) of the Smart Client Software Factory?
A: Our understanding is that this is on the SCSF roadmap.
To be honest, it has been on that roadmap a long time and it keeps getting bumped. The folks at PnP respond to community votes and, it would seem, the voting community wants features more than it wants VB. I think PnP should consider the "silent plurality" and I will say so.
Of course I've been a culprit in this too. I converted the key parts of Cabana to VB once. But I've forged ahead in C# and the VB lagged. I intend for the VB to catch up in the next week or so; but you know where that road leads.
Q: Is CAB meaningful to VB developers?
A: Yes, yes, yes!
Actually, I think CAB itself is available in VB. The SCSF is not in VB yet. But that really shouldn't stop you.
You may say "well the recipes only generate C#". I have a confession. I don't use the recipes. I used them once, to get started and never used them again. Ok, I'm weird. I really would like to use the recipes (and will do so as soon as they fix a few things). Meanwhile, I'm making use of all the rest of the CAB + SCSF goodness.
And I can do so in the language of my choice. If I were you, I'd just leave CAB and SCSF projects in their native C#. Forge ahead with your application in VB.
Of course it won't be perfect. You should be able to read C# if you have to - we should all be able to read either C# or VB. The debugging experience is not as nice when you have to cross a language boundary. But its livable and worth it in my opinion.
I say this from some experience. I translated a lot of Cabana into VB for a client; I left core parts of the infrastructure in C#. It wasn't hard to live in the VB projects.
It beats the alternative.
Q: I notice that PnP hasn't updated the CAB CTP since December 2005. What are Microsoft's future plans with regard to CAB? Will CAB become obsolete?
A: Murray and I try to answer that in the webinar. We've asked the PnP team the same question. Unfortunately, there is not much that we are permitted to tell you.
We can say that CAB is regarded as a big success in Microsoft. I know some heavy hitters in the developer community who have dedicated serious cash, job security, and prestige to their CAB-based apps. CAB may change over time but the fundamentals are sound and it is going to be a part of the .NET eco-system in one form or another for years to come. This is no flavor of the month.
If you are wondering "is CAB worth learning today?" or "is do I risk building with CAB today?", I answer, emphatically, "yes!"
If you have to know more, contact the PnP team yourself; if you are persistent and have a compelling, business-driven need to know, I think you will get the answer that you need.
Q: Does the smart client software factory replace the need for a framework?
A: Absolutely not!
Both CAB and CAB+SCSF are just glue. You have to supply the parts to glue including an enormous amount of foundational material. You can pick up some of the infrastructural components from open sources such as the PnP's own Enterprise Library. Even then, I think you leave yourself with a lot to do.
Here's my shameless commerce moment although I believe it to the depth of my soul: you will save money, time and trouble if you buy application infrastructure from a reputable vendor - like IdeaBlade.
This answer in no way diminishes the considerable accomplishment of CAB + SCSF. It may be "just glue" - but it is great glue and, without it, you'll have a pile of parts and pieces that don't stick together well.
In the webinar we compared CAB to Web Services. I don't think any one would ask "Do Web Services replace the need for an application framework?" We all understand Web Services a little better now; we are pretty clear about what Web Services do and what they don't do.
We lack that clarity vis-a-vis CAB. So people are more likely to think that CAB addresses everything in the way they might once have thought that Web Services solve everything.
Q: Can you learn CAB from the Smart Client Software Factory or do you need to start with the Composite UI Application Block?
A: Please see above where I talk about how to learn CAB + SCSF.
Perhaps it is worth repeating. Every SCSF application is a CAB application. SCSF adds value to the CAB layer. Accordingly, when you examine an application built with SCSF, you are learning CAB and SCSF at the same time.
There are reference applications for both SCSF and CAB. The CAB reference apps happen to be WinForm applications so they are both "smart client" apps (leading to some confusion I suppose).
All of the reference apps are worth a look. Just remember that the SCSF apps apply a slightly different twist to some of the design patterns.
I might as well plug Cabana once again as yet another way to learn CAB and SCSF design principles.
Q: Do CAB or SCSF provide multi-language support?
A: They neither add to nor detract from .NET's mult-language / multi-culture support. At least I am unaware of anything in either CAB or SCSF that addresses this issue specifically.
Q: Is there a Vista upgrade plan?
A: Yes. Vista support should be available "very soon". Really.
Q: Does CAB support Windows Presentation Foundation (WPF)?
A: Actually, CAB supports any kind of client technology. CAB is client agnostic.
The PnP team is developing a WPF version of the Smart Client Software Factory. That should arrive "soon" too.
This really intrigues me because WPF is much more than another control suite (the impression one gets from the marketing). It is far more than XAML and code behind. There is a lot of new architecture in there. Many of the new constructs (dependency properties, routed events, routed commands) have a lot in common with features in CAB that people have claimed are too "mysterious".
If you've been looking at WPF, you'll see instantly how CAB and WPF are made for each other.
That said, I really wonder who is going to do serious WPF development in the absence of adequate visual design tools. It's going to be a long time until Orcas gets here. I'm not a huge fan of wrangling XAML by hand.
Q: Can we integrate WCF into a CAB app today?
A: Sure.
CAB itself doesn't have anything to say on the problems for which WCF is the appropriate solution. There is no specific "home" in CAB for WCF that I am aware of.
CAB concentrates on the plumbing necessary to glue together components within the same process (indeed, within the same AppDomain). WCF concerns bridging process boundaries.
I'm no expert on this, as someone is sure to observe. I think Juval talks about using WCF to wrap access to integers or something like that.
So the PnP folks may have added some WCF sauce that I don't know about. Visit the PnP Smart Client website to find out more.
Q: What was Murray's Blog url again?
A: http://www.geekswithblogs.net/murraybgordon
