Pattern Pain

Dec 7, 2008 at 1: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!

Brette
Dec 7, 2008 at 6:35 PM
Brette,

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 http://msdn.microsoft.com/en-us/magazine/cc785479.aspx 

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
http://www.xentree.com/SL2WithPrism/CodeWalk/

The project itself is located at http://www.codeplex.com/SL2WithPrism

Regards,
Alexander

Dec 7, 2008 at 10:34 PM
Alexander,

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.

Brette21
Dec 7, 2008 at 11:06 PM
Edited Dec 7, 2008 at 11: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) http://en.wikipedia.org/wiki/Separation_of_concerns , and the single responsibility principle http://en.wikipedia.org/wiki/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

http://martinfowler.com/eaaDev/uiArchs.html

 

Retirement note for Model View Presenter Pattern

http://martinfowler.com/eaaDev/ModelViewPresenter.html

 

Regards,

Alexander

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