locked
CAB - Composite UI Application Block RRS feed

  • Question

  •  

    WOW! That's all I gotta say.

    I'm actually trying to get into grips with this as I have just started in a new contract and the current project is using this. Most people have no idea how to use it or are kind of getting into it but not so much.

     

    I've read as much articles as I could but still don't quite get the whole thing and how it works. I know its basically a loosely coupled architecture for the UI where you can "plug in" a new UI should you need to, your Business and DAL layers remain uneffected generally.

     

    I just don't get the whole thing. I mean, how would one create say the UI, plug it in using the CAB?

    how does it function?

    What is the need for IWorkType? etc... etc... - these fundamentals I do not quite understand and would appreciate if someone could help me/guide me - infact would be a great discussion to help each other in this newbie topic for this pattern.

    Wednesday, October 3, 2007 8:12 AM

All replies


  • A lot of the principles behind the CAB have been explained excellently by Jeremy D. Miller in his series of blog posts as he explores the patterns and practices behind seperation of concerns and testability where your dealing with the UI.

    http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx

    Jeremy's blog is excellent, one to add to the feeds in your reader

    Regards

    Ed
    Thursday, October 4, 2007 7:34 PM
  • I agree that Jeremy's posts are great, but they won't (and where not intended to) get you up to speed if you want to use CAB and SCSF. Also, if you have a choice you should definetly be using SCSF and not bare-bone CAB.

    I don't know what you have already read, but I have written up a "Get Starting Guide" that we use. You can have a look at that.

    http://www.renaissance.co.il/downloads.aspx

     

     

    Thursday, October 4, 2007 7:57 PM
  • Many thanks for this i will take a look

     

    I actually had an email from a SQL MVP here who is also on the forums but couldn't post yesterday...so here is a cut/copy of the email for everyone's benefit and contribution:

    Check the Smart Client Software Factory (http://www.codeplex.com/smartclient). Doing CAB without it is almost impossible. It has a very good overview of what CAB is about ( http://msdn2.microsoft.com/en-us/library/aa546409.aspx).

    Roughly speaking, WorkItems are equivalent to Use Cases. You could have one WorkItem for each Use Case in your application. A WorkItem includes the Services necessary to execute the Use Cases and Views to communicate with the user. Views are UserControls based on the MVP pattern. WorkItems, Services and Views are packaged in Modules which can be loaded individually. You can think of Modules as the mini-apps or separate legacy apps that comprise your composite application. WorkItems can contain other WorkItems just like Use Cases can include or be extended by other Use Cases. Child WorkItems have access to their parent's services. There is also an event mechanism to allow different WorkItems to communicate.

    Rough Design Guide:
    1. Define the app's Use Cases. Package them to reduce dependencies
    2. Define the control/worker entities and business processes necessary to execute the use cases
    3. Design the UI for each Use Case
    Then
    1. Create WorkItems for the Use Cases and package them in Modules corresponding to the original packages
    2. Create services corresponding to the control/worker or process entities
    3. Create Views for each UI screen

    The SCSF automates many of the steps.

    Sorry for the terse answer, but I just can't retype two hours worth of stuff! Go see the webcasts. They are good.

    Or come to Teched Developers in Barcelona.

     
    I have read the SCSF stuff and it does make sense, but wish there were more examples. Still trying to grasp the idea and how the BusinessLayer and DAL layer come into play.
     
    So say we had a customer object, contains the obvious like firstname/lastname etc.... and we had an Account class, 1 customer can have many accounts, thats all very well (accounts include transactions (withdrawel,credit etc..)) - so how would this fit in with the workitems/module/smartpart etc...? What about when it needs to access say SQL from the DAL to get details of a customer/account and perform transactions?
     
     
    im impressed and amazed at the attributes and how it works like [ServiceDependancy],[EventPublication]?,[CreateNew] etc... - pretty cool how that works and how the ObjectBuilder does all that for you.
     
    But its things like, ok well how would I prompt the user for input in a textbox of a SmartPart? Would that "prompt" come from the usercontrol itself? Or would it be from a WorkItem where it would access a Workspace where the SmartPart is located and raise an event or something to the smartpart to do that? Sorry, I am confused/unclear about things like that.
     
    Normally would do do this at the UserControl level and do a simple MessageBox.Show(); to show a prompt to the user for whatever reason. I know its the same code but called in some different way due to this CAB architecture
    Thursday, October 4, 2007 8:35 PM
  • A few comments:

    1) The one WorkItem per UseCase is no longer considered best practice. In SCSF you use WorkItemControllers. Read up on those. There are several threads on CodePlex that should give you some ideas. In one of the podcasts (A link in the article I referred to in my last post) by Peter Provost he talks about this issue as well.

    2) CAB/SCSF is all about the client. While there's support for disconnected clients 99% of the focus is on what you do once you're on the client.

    3) Any interaction with the user is usually done from the presenter. The WorkItemController is "just" orchestrating and managing interactions between it's views. For your example of a MessageBox, you would not display a message box from the presenter since that would make it difficult to test the presenter. Delegate that to the view, or use a MessageBoxService (That you write) instead. Search CodePlex forums for MessageBoxService and you should find some code.

     

     

     

    Friday, October 5, 2007 1:41 AM
  • YES! I CAN POST AGAIN!

    The one WorkItem per UseCase is no longer considered best practice. In SCSF you use WorkItemControllers. Read up on those.

    Ooops, sorry about the mixup. My post was too terse anyway, because the forums had just rejected my several-page-long answer. I just didn't have the courage to go and write things all over again - and I didn't want to confuse things. CAB+SCSF contain so many different concepts it's hard to give a quick overview without going into too much detail.

     

    The fact remains, that WorkItems and WorkItemControllers have a close relationship to Use Cases but they don't have to correspond 1 to 1. In fact, the WorkItems (the code artifact) act as a container. The programmer creates a related WorkItemController with the code that executes the use case. It is the concept of the WorkItem that corresponds to the concept of the use case. And, just as you can have multiple use cases served by a single class, you can have multiple use cases controlled by a single WorkItemController.

     

    By the way, I REALLY dislike the WorkItem and WorkItemController names. Way back, when CAB was still in beta, they used to call them Contexts - and that was confusing too.. I realize, they couldn't call them UseCaseItems, because there no direct one-to-one relation. But WorkItems? Aren't we getting too abstract here?

    Friday, October 5, 2007 6:51 AM
  • I hate CAB.

    Monday, November 17, 2008 8:59 PM