Pattern Pain

Dec 7, 2008 at 12:59 AM
Ok after a few weeks looking at the Stock sample application I am hoping I can get a little confirmation on some of the patterns. Namely the PresentationModel pattern. For the most part I understand that pattern and I really like it for UI frameworks with strong databinding support such as WPF. However in the sample application I get a little mixed up because there seems to be a lot of intermixing of the patterns.

The source of the confusion is around the use of the service classes and the controller classes. For instance in a PresentationModel pattern you have the following artifacts.

View --- PresentationModel -- Model(Objects)

However in some cases it looks like there is a controller and service added into the mix to make something like this.

View --- PresentationModel -- Controller -- Service -- Model(Objects)

Also throughout the application presentationModels have references to services and controllers and other presentationModels. And in the documentation this is never discussed. Could someone please fill the gaps for me?

What role do the services classes play? And when would I decide to you use one, as opposed to hitting the model directly from the PM? Same questions with the controller classes.

Any insight would be great. Thanks for all the work guys!

Dec 7, 2008 at 5:35 PM

There is a great article from Glenn Block on MSDN Magazine that describes the Prism for WPF and these patterns in generally. See the link 

I have one quick screen cast of this on my CodePlex project where I Walkthrough the Alfa 1 code. I quickly explain the views, presenters, and models (supervising and passive), service and controller on the project code. Take a look the link below and see if it helps

The project itself is located at


Dec 7, 2008 at 9:34 PM

Thanks so much for the info. I watched your presentation, and very much enjoyed it. I also just read the article you mentioned this was also very good. With that said, would it be sufficient to say the following.

In the Model View Presenter and the PresentationModel patterns, a Controller class is used as a type of mediator to facilitate View to View communication. Or in other words a Controller provides a contract and implmentation that two views agree to communicate with.

I think the light bulb is finally turning on. Please correct me if the above statements are incorrect.

Thanks again this forum has been very helpful to CAL newbe like myself.

Dec 7, 2008 at 10:06 PM
Edited Dec 7, 2008 at 10:07 PM

You are right, please keep in mind that I followed the principal of separation this way, someone else could add something else on controller as it would make sense on that design or requirements.  You are on good practice as long as you follow the rule of separation of concerns (SoC) , and the single responsibility principle in your design and coding that utilizes the MVP concept.


If you want to learn more about it, see Martin Flower’s site,


GUI Architectures


Retirement note for Model View Presenter Pattern




Dec 7, 2008 at 10:42 PM
Good stuff! Thanks again for the help. Very excited to be using teh CAL. Looks like it was very well thought out.