WorkItems and Controllers

Topics: CAB & Smart Client Software Factory
Jan 20, 2006 at 3:54 PM
originally posted by: bartekp


I wonder if calling WorkItem's methods from Controllers is a good practice. It limits their reusability and makes the MVP/MVC triad usable only inside a specific WorkItem.

In my opinion a Controller should be completely unaware of its container's interface and simply modify the State and/or access registered services.

Jan 20, 2006 at 8:22 PM
originally posted by: rxd9507

Actually this MVC patterns is so used/abused that it is difficult to find who is right.
My take on Work Item is that although it is a mini MVC that can further call other Macro MVCs, at the end of the day it is a controller. By definition controller is the glue code that is never meant to be reusable.

Actually look at MVC and sometimes it gets so complicated that you want to recur...

WI = again MVC where v = smart part, model = business entityfacade layersservices, controller = a simple pass through

Jan 22, 2006 at 7:22 PM
originally posted by: headlam

In general I agree with your statement. If you approach the design with the assumption that the Controller (or Presenter) and the View (i.e., User Control, etc.) together represent the greatest area of reuse, I think you will be better off. View the WorkItem as the entity that binds them together and causes the various strategies to take place (i.e., service injection, etc.). The WorkItem is also responsible for displaying your view in a particular workspace, and can also hold state use by the controller or view. Build it is such a way that you can reuse the controller/view combination with any other WorkItem. In the case where the WorkItem is managing multiple controller/view combinations, view the WorkItem as an application controller. Communication between the view and controller should be done via an interface (my opinion). This will also help with testing the controller independent of the view. It also allows for replacing the view with a different implementation (so long as it implements the expected interface). Your business entities, service agents, etc. will serve the same purpose as before – only now you can set a reference to an instance via DI and have some additional capabilities that would require a lot more work in the past (had you not use the CAB). Keep the bulk of the work in the controller/presenter. Use services that make sense for you. Understand that CAB services are not web services. Don’t overuse WorkItems (i.e., if your application will allow for multiple views/controllers in a single WorkItem… do it).

All that being said if you have no need for decoupling the WorkItem from the View or the Controller/Presenter CAB will not prevent you from doing so. You just need to understand what you are doing. And always do what is best for you particular situation.

Mar 30, 2006 at 12:36 PM
originally posted by: turmelma

I tend to agree with that last post in general.
I am also thinking about WorkItem organization in my CAB modules, and although so far I had gone with an approach similair to what the CAB documentation and samples points one to, I am starting to think it's not suitable for all situations. One symptom that lead me to that thinking is the fact that my WorkItem subclasses contain practically no code but the creation of the View object and its showing in a workspace passed by the parent.

In complex applications where many use-cases are interrelated I think what Norm suggests might be a better approach. The unit of reusable code is the View/Presenter combo. Independance from container WorkItem seems like a good design goal to me as well. I also use an interface to decouple the View from the Presenter. Much more flexible as far as View implementation is concern (WF UserControl, WPF, Web maybe? ...).

Any reactions or comments ?