Why should I use the Composite UI?

Topics: CAB & Smart Client Software Factory
Jul 27, 2006 at 2:29 AM
originally posted by: sprotty


I have been looking at the Composite UI for a couple of days, and I think I’ve got the basics of the interactions, but I’m struggling a little with the motivations behind them.

Now maybe it just does not fit with the style of application I am developing, but before I discount it I would appreciate knowing the reasons I should use it from people who are using it.

Before I go any further I’ll outline what I am trying to develop.
We need an extensible portal style application. There will be a dynamic tree of items, and clicking on the tree will create a UI (display/edit/report) component. We could ultimately end up with 100 say modules, so the application must load on demand, not load them all up front. The modules will have only a little to no interdependency (maybe refresh events when data changes), but will need to make use of common services.

Now what are the benefits of using the Composite UI, as opposed to creating a form, defining an interface that the controls must implement, and allowing them access to the shared services via that. I see some advantages to the event model in the CAB, but this seems like it could be replicated with a very simple subscription model. The UI components don’t seem to offer anything that is not already available.

Basically I can’t see the benefit of what the CAB describes as loose coupling when you still need to reference objects in other assemblies, and I’m not sure what actual benefit the magic loading is. The event subscription mechanism seems to have merits, but at the same time looks error prone, a typo in the event name could take hours to track down.

Thanks for any feedback,


I am looking for reasons to use this (not just wind people up), the CAB seems to have a reasonable steep learning curve associated with it, and any feedback here would also be to new other comers.
Jul 27, 2006 at 5:44 AM
originally posted by: askew

You should use the SCSF for CAB solutions, imho.

The loose coupling allows for plug-ins that can be smart as you code them; no binary dependencies to cause the application to need to recompile. They are logically bound through interfaces instead.

You can outsource module development, and not be dependent on it for compilation.

There are many 'best practices' revealed with the CAB and its source and the SCSF solutions of the CAB framework.

SCSF's community site is gotdotnet also:

There are articles on loading modules on demand, and while they cannot be unloaded afterwards, the garbage-collector will free up memory associated with them when they are closed. CAB scales well, make no mistake.

You have an application framework ready to use.
The learning curve is worth the effort if only to learn from the source code.

My .02
Jul 27, 2006 at 6:41 AM
originally posted by: ChrisHolmes

"The event subscription mechanism seems to have merits, but at the same time looks error prone, a typo in the event name could take hours to track down."

And that's why most of us write a class like EventTopicNames and then provide those names as const strings, so we can do compile time checking and never have to worry about a misspelling. Same with CommandHandler names, WorkItemNames, SmartPartNames, etc...

The benefit of the CAB is you don't have to spend months writing an application framework yourself.

CAB provides several advantages:

(1) ObjectBuilder - the Dependency Injection framework. Honestly, I can't imagine trying to build a large scale modular application without some sort of DI framework. You could get that from Pico or Spring.NET as well, but that is all they do. They don't come with EventBroker, ServiceLocators, CommandHandlers, etc.

(2) EventBroker .

(3) CommandHandlers - for MenuStrip and ToolStrip type commands. Very useful.

(4) WorkItem container. WorkItems are neat things. They are essentially a container for various chunks of code, like Services, SmartParts, Workspaces, etc. They expose Collections of those items and they already have strategies built in for the Dependency Injection framework. They are the core of working with CAB and they make it very easy to setup Use Cases for user interaction. They keep things small, logical and functional.

(5) Workspaces - great components for managing all the SmartParts. They handle all the showing/hiding and can also use Dependency Injection if they need references to a Service or whatnot. The usefulness of these can't be understated when you start having to manage a lot of views.

Really, the CAB is all about making things easier to manage in a large scale applicatoin. Yes, you could do it all manually and manage everything yourself, but it would take more code and more development time. Once you get past the learning curve the CAB makes developing new Use Cases - new WorkItems, Views, etc., much simpler, faster and effecient. And if you have Guidance packages to aid you, it's even better.
Jul 27, 2006 at 7:07 AM
originally posted by: sprotty

Thanks for taking the time to reply.
I'll do some more digging on some of the areas highlighted, and come back when I have a better grasp of things.

Cheers Simon