MVP / Supervising Controller CSLA Example?

FireGarden posted on Thursday, August 31, 2006

I just finished reading a great article on MSDN about the MVP presenter pattern  as follows:

http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx

In researching the pattern I also did some reading on the current state of the pattern and found it was split into two patterns:

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

I am wondering if anyone has a 'best practices' code example they could share of an implementation of either of these pattern flavors?

I am curious to see if a service is built inbetween the businss objects and the presenter. Also some examples of how data binding is handled as noted in Supervising Controller.

Regards,

Rob Wheeldon

FireGarden replied on Thursday, August 31, 2006

Come on guys,

We are all using Csla as a framework. It's great we have  recognized the benefits of building applications with a  framework like Csla. Lets get some discussion about how this frame work fits into solutions using simple design patterns like the MVP pattern.

If you are new to the concept of design patterns I reccomend Design Patterns Explained (2nd edition). I am new to patterns and quite frankly I am wearing a diaper to stay clean.

Lets all be conscious of UI Architecture. Model view presenter is a great pattern to base your UI around. So pull up your pants people and learn MVP then post some creative implementations using the Csla framework.

I don't think this is off topic of "Csla discussion". Csla is a great place to live but it's only a piece of the big picture. Lets all be conscious of the big picture because it will give us better understanding of the parts.  I live on this planet but exist in a solar system.

In closing I love this Csla community.

Rob Wheeldon

alandotnet replied on Thursday, April 05, 2007

Hi Everyone,

We have just convereted a very large CSLA Project over from CSLA 1 to 2. We are looking to rewrite the enire windows forms interface now. I work with a programmer who is pushing the idea of using th MVP patturn to contruct this new windows forms UI.

I have some concerns though. I dont understand the MVP framwork fully yet, so its hard to say if my concerns are warrented.

Rocky has mentioned is this post http://forums.lhotka.net/forums/thread/7842.aspx that some of the patturns overlap what is already in CSLA...

There is an AWFUL LOT of work in creating a new UI. I want to make sure we do it the best way possible.

Has anyone here used the MVP patturn for a project? Id love to know how it went/how its going?

Can anyone (Rocky maybe) tell me if the MVP does in fact cover any ground already covered by CSLA.

Thanks

Alan

ajj3085 replied on Thursday, April 05, 2007

alandotnet:

I work with a programmer who is pushing the idea of using th MVP patturn to contruct this new windows forms UI.

Well, patterns should evolve naturally as you program.  You don't start out with the idea that 'we will use pattern X,' you program until you encounter a problem, then decide 'does pattern X help make this easier to maintain.' 

Tell your coworker to check out Head First Design Patterns, especially the last few chapters.  It has very sound advice about when to use patterns, but also when NOT to use patterns.

Bayu replied on Thursday, April 05, 2007

Aight,

Let's see if I can add someting of value. ;-)

I have been using MVP/MVC for quite some time now. But I am not really following a strict recipe. I think that is how design patterns should be leveraged: pragmatically. As a result, I don;t really have a clue whether I am doing MVP or MVC, but I think a lot of people have trouble making this distinction and as you pointed out even Martin Fowler is not sure. For effective use though it does not really matter, as long as it works, right? ;-) So from now on I will refer to the Presenter or Controller as if they are the same thing.

I think that the keyword in MVP/MVC is reuse.As someone pointed out: building UIs is a time-consuming task, add to that that most applications have a lifespan that spans at least 2, but perhaps many more UI technologies (now it's WPF, who knows what it'll be in 2010).

In my opinion you have successfully implemented MVC/MVP is you achieved the following:

- you can reuse Views independent of the attached Controller/Presenter
    - e.g.: depending on the attached Controller/Presenter you View shows different elemtns of your model (business objects)
    - and/or exposes different behavior

- you can reuse Controllers/Presenters across different views
    - depending on the view your model is rendered in a particular way
    - but the behavior on your Controller is reused


Let's jump to an example, in my current app I have the following Views:
- DetailsView
    - displays the details of a single object using a grid-layout (tablelayoutpanel)
    - can render arbitrary objects (uses a lot of reflection)
    - typically, the labels with property names are in the odd columns and their values are displayed in the even columns
- GridView
    - can display a list of items, also using reflection it determines which columns should be created for the object's properties
- Several more views that mostly serve to organize the overall layout, most importantly I have a ParentChildrenLayoutView:
    - show a DetailView at the top
    - and shows one or more GridViews in a TabControl at the bottom

Both the DetailView and the GridView are capable of rendering objects in readonly mode and in editmode. In the latter case the detailview will show things like comboboxes and textboxes and the gridview will allow the user to add new rows.

Then I have the following Controllers that can be attached to these views:
- ReadOnlyObjectController
- EditableObjectController
- ReadOnlyListController
- EditableListController

The readonly controllers require the view to implement IReadOnlyObjectView and the editable object controllers require the view to implement IEditableObjectView. Both these interfaces are implemented by my views of course.

Now, it's not hard to see how I can support almost all standard use cases with just this handful of views and controllers. Suddenly, UI development became a REALLY fast-paced track of development, since in order to support new business objects/use cases I hardly need to program any UI code. And of course there are some of those views that do not fit in the standard pattern, these can choose to derive from one of my base views or they can be built from scratch. Possibly I can reuse a controller, since usually that logic does not change (it's just the rendering logic that changes). The same holds true for complex use cases that require specific controllers. Think of a Wizard like interface, this requires a new controller but can be built mostly using existing views. Remember: MVP/MVC is all about reuse.

Unfortunately I cannot share any code, but I hope to have given you some basic ideas to get started with.

Regards,
Bayu