When should the presentation model design pattern include one or more controllers?

Question

I have been researching the usage of the Presentation Model design pattern for an application I am preparing to build. The specific technology I will be using is Flex though I doubt that it matters for this question.

In general most of the Presentation Model examples I have run across are pretty consistent in the basic implementation. More or less they follow Martin Fowler's Presentation Model description to a T when it comes to the three basic concepts: View, Model, Presentation Model.

I think that I understand this.

However, I have seen some other examples that extend this further by including controller, event, and service objects in addition to the three basic constructs I listed above. The examples I have seen are (note these are both using Swiz for DI and event handling):

I understand the reasoning for a service layer. You may want / need to retrieve your data from a SOAP interface one day, a REST interface the next, and a SharedObject on the third day. The service layer interface makes it easy to swap out retrieval and persistence logic.

However, I am not sure that I understand why the addition of the controller is an advantage?

In the examples linked above some logic within the presentation model is dispatched and handled within the presentation model itself while other logic is dispatched and addressed within a controller.

My guess is that logic that is view specific is captured within the presentation model. This supports the notion that the presentation model is simply an abstract representation of the view.

Further, I suspect that the controllers are used to capture common business logic and events that are not view specific and are not performed by the service layer (e.g., persistence). This should support reuse across the application and help to make the application more testable.

Is this conclusion right?
Are there other advantages I am missing?
What are the disadvantages (besides more code)?
How do you know when logic should be in the presentation model and when it should reside in a controller?

I added presentation model, but also MVVM as I believe that MVVM is a more recognized term. — Demian Brecht, Oct 05 '11 at 17:27
I think MVVM is applicable too as the two design patterns are so closely related. Thanks for the addition. — Ryan Taylor, Oct 05 '11 at 17:35
MVVM is actually *based* on the presentation model design pattern :) — Demian Brecht, Oct 05 '11 at 17:47

score 1 · Answer 1 · answered Oct 05 '11 at 18:32

The basic reason for a controller is Separation of Concerns... What you describe is a combination of the MVC and the MVVM patterns, which indeed is my approach of choice.

Basically you have your usual Model View Controller, but you add in the ViewModel. This helps you build more reusable code and have a true separation between you Data Layer, your Business Logic and your presentation.

Disadvantages? well, like you said more code. Other than that, non that make me think twice about it.

Where should logic be? Business Logic in the controller, Presentation logic in the ViewModel and the View.

When should the presentation model design pattern include one or more controllers?

1 Answers1