WorkItem/WorkItemController?

Topics: CAB & Smart Client Software Factory
Jun 15, 2007 at 8:10 PM
Why would one use a WorkItem vs a WorkItemController? If a WorkItem can have child WorkItems, when should one be used vs the other? ModuleController is of type WorkItemController. Should one use a WorkItemController only at the module level?
Jun 16, 2007 at 3:33 PM
In the reference applications the WorkItemController is always the topmost, root element in the workitem hierarchy. From my point of view, it's just an unnecessary layer of indirection. In our shop, we always inherit from WorkItem classes.
Jun 17, 2007 at 1:33 AM
Thanks, Chris. For anyone interested, I found this info at http://staff.southworks.net/blogs/mariano/archive/2006/10/11/5B00InheritState5D00-attribute-working-in-SC2D00SF-based-applications.aspx. Still not sure exactly what the difference is or why one would use one vs another.

"To implement a new type of WorkItem, you don’t extend the WorkItem class anymore – you derive from WorkItemController. These classes, ControlledWorkItem and WorkItemController, where introduced in SC-SF to separate the containment functionality from the business logic to fulfill a use case (respectively)."
Jun 19, 2007 at 2:26 PM
Edited Jun 19, 2007 at 2:27 PM
Before I explain, bear in mind I am no guru, but I did have the privilege of attending a Dave Platt seminar back last October.

I think the terminology might need to be cleared up in this case.

First of all, let me define terms you're using:
WorkItem: The SC-SF frame of mind is to think of this as a Container. A scoping Container for all of the objects used in CAB. (e.g. For the application we're coding, we have SmartParts, BusinessObjects, Loosely Coupled Events all sitting in a WorkItem "bucket" if you will )

WorkItemController: Tied to the workitem. It's where handler functions live. That is where the CAB team is recommending you place your business object methods.

Now, if you use SC-SF and add a new "Business Model", one of the things it does is add two classes:
1. Module.cs (Uses something called "dependency injection" to Make CAB see that it needs to load it when the app initailzes. Once it is to the rootWorkItem, it calls the "Run" method on the controller (the class below)
2. ModuleController.cs (Inherits from workItemController and thus, is a dependent service on the WorkItem. Our app has EventSubscriptions in here that we use to launch functionality within that particular Business Model).

That's it in a nutshell. I hope that helps.

If you put breakpoints in these classes on their initialization and run the app, I think it might be a little more clear.