WorkItem vs. Controller

Topics: CAB & Smart Client Software Factory
Jul 7, 2005 at 8:32 PM
originally posted by: nphelps

I'd like to hear some examples of the usage of a WorkItem vs. a Controller as I am currently confused on this topic. And what is the significance of the DefaultWorkItem?
Jul 8, 2005 at 11:10 AM
originally posted by: BradWilsonMSFT

We see the work item as a container that's in aid of a use case. It contains, generally speaking:

- Business entities (models in MVC)
- View/controller pairs
- Sub workitems
- Services
- State

(There are probably other things I'm missing, but this is the core.)

The WorkItem is the natural organization place for your units of work. Controllers, on the other hand, are generally tied to one view (or a few specific views), and are there to represent the business logic that the view needs to use. Some of those things might be self contained (i.e., the controller has all the information is needs), and some of those business action items might forward up to the WorkItem (i.e., when the action is one view needs to cause another view to come into existance).

The DefaultWorkItem is... well, maybe not fully baked. In our examples, we saw a recurring pattern of a single work item at the top of the hierarchy (directly embedded into the ApplicationHost), where the application shell resided. We started off using a magic "name" to register the default work item with, and ended up refactoring a default work item into the ApplicationHost container. I'm not sure we're convinced this is right yet, but that's why it's a CTP. :) Suggestions/comments are most welcome!
Jul 8, 2005 at 11:31 AM
originally posted by: FrancoisTanguay

Suggestion:

Make ApplicationHost derive from WorkItem (Is is the root work item after all)

Remove DefaultWorkItem
Remove WorkItems property
Jul 10, 2005 at 7:11 PM
originally posted by: nphelps

I guess some of my confusion is related to where state/model management should go.

Say I have a view with a combo box that needs to be loaded in the onload event from a web service call. There are two ways I could handle this:

1.) The view's onload event could call a method on the controller which utilizes a reference to the webservice via a component dependency within the WorkItem to invoke the web service method and return the values to the view. This would produce a controller that would look like this:

ComponentDependancy
private MyWebService myWebService = null;

public List<Task> GetTasks() {
return this.myWebService.GetTasks();
}

2.) The view's onload event could call a method on the controller which utilizes a reference to the actual state using a state depend which had been pre-retrieved in the WorkItem. This would produce a controller that would look like this:

State(“Tasks”)
private List<Task> tasks

public List<Task> GetTasks() {
return this.tasks;
}

In the first scenario, the Controller would be the one invoking the webservice and in the second, the WorkItem would be invoking the webservice. This is where my confusion is. In the CAB documentation, in the Developing Using MVC and WorkItems section the CustomerListController uses the 2nd pattern, but I would imagine this leaves the controller doing very little. What is the right approach?
Jul 27, 2005 at 8:02 AM
originally posted by: aaguiarz

What happens with 'simple' use cases, that have only one form and some basic CRUD functionality?

Should they have a WorkItem and a Controller anyway? If so, what should I put in each one? If not, I guess it should not have the Controller, as it looks the WorkItem is a more important piece in the architecture...
Sep 3, 2005 at 12:34 AM
originally posted by: wolf5

I am also confused on this topic. It feels like the Controllers only real use is to pass calls to the WorkItem.

The only use I could see with the controller is perhaps when a user presses a button, a textbox is made visible or some other UI interaction. Is this basically what we use the controller for (UI logic on user inputs) ?