WorkItem name revisited

Topics: CAB & Smart Client Software Factory
Jun 29, 2005 at 2:34 AM
originally posted by: eilert

I don’t known if it is still possible to refractor the ‘WorkItem’ name to something that it is more descriptive to what it really is. For me an Item is a single thing. However 'WorkItem' has more of the behavior of a container. I propose ‘WorkContainer’ or ‘WorkBin’ or maybe ‘WorkUnit’. Come to think of it WorkItems have ‘Run’ and ‘Activate’ etc methods, which are not so appropriate for real world containers, which Open and Close. Maybe ‘WorkUnit is a better compromise.
Jul 1, 2005 at 5:40 PM
originally posted by: EdJez

We will have to give a big prize to whoever comes up with a name for workitem that sticks... and we haven't asked Ward yet - he is a master at names
Jul 3, 2005 at 3:04 AM
originally posted by: ptorrsmith

Jul 3, 2005 at 3:09 AM
originally posted by: ptorrsmith

UseCase, or UseModel.

The latter is better for me as, since the current WorkItem (UseModel) holds the State, it is filling the Model role in the Model-View-Controller pattern.
Jul 3, 2005 at 11:26 AM
originally posted by: EdJez you can see this is not trivial here are additional and already mentioned options:

Let's see if any combination of {work, unit, session, context, task, use case, controller, set, container}

also we have considered:
Application Controller*

  • after the patterns of equivalent names ref Fowler and POSA? respectively

The way I see it, the WorkItem isn't the model, it holds a reference to the model shared by many views and controllers in blackboard style, and encapsulates the application-controller-like behavior for one use case. Does this match with your view?
Jul 3, 2005 at 4:44 PM
originally posted by: ptorrsmith

You guys envisioned and designed this AB and have pulled it all together, you are the best ones to define the role/s and name of the "WorkItem" container/controller. I like UseCase, as my fellow developers and managers can understand and relate to that concept. I agree the workItem isn't only the Model, and is the app controller for a usecase. But it is where the model elements (state dictionary) reside, so in this respect is providing the "model" role in the MVC view of the world (and more). Hence UseModel.

Since the WorkItem is like an application controller, I do have difficulty however when trying to explain to colleagues the differences between WorkItem and Controller, or more importantly when, and what type of code/logic to stick in the controller(s) and the workitem. This is particularly important when we are building our app over a service layer, and trying to define some guidelines as to where various types of business and process logic should be placed.

So at the end of the day, the name is reasonably important, but what is more important is having clarity as to what the roles/responsibilities are for each of these classes/containers... ideally in reference to the reasonably well understood MVC approach (see my post "Controllers and WorkItems" 06/28/2005).
Jul 3, 2005 at 10:02 PM
originally posted by: primozs

WorkItem - A runtime container of the components and services that are collaborating to fulfill a use case.

As i understand it now after some examples and rereading the definitions, WorkItem is exactly what the definition say.
I think the name is fine.