This project is read-only.

Presenter Design

Topics: Developer Forum
Jan 25, 2007 at 8:19 PM
I am using this framework for my presentation layer of a work project. I like the beginnings so far and want to give you guys some real use feedback, so here goes:

I am looking at the SaveCore() method, and I am assuming that it saves information from the view to the model. Is this correct?

If this is correct, I think it would be a good idea to aim for some flexibility in the model's updating granularity. i do not know what the roadmap is exactly concerning the presenter, so this may already be in discussion.

Here is an example of potential flexibility (using the Supervising Controller pattern):
Let's say I have a view that displays a list of store locations (with the address, Company name, etc.). the view then adds a new store to the list. This triggers the presenter to update the model. Now, if I were to use the SaveCore() method, inside the method I would grab the current list from the view then I would have to either update the entire list at once and let the repository determine what is new and what is not, a potentially expensive process, or maintain a "current item" property in the view that the presenter uses to add to the repository. From my experience, the second option sounds fine in theory, but, from my experience, it does seem to add unnecessary complexity to both the view and the presenter (for example, the view now needs to maintain a pointer to the current item and know when to change it, etc.).

My suggestion, and what I am currently doing is this:
I decided to instead create an ItemAdded event, which has a generic ItemEventArg<T> object that contains an item of the generic type as a property. the presenter handles the event and passes the arugment's Item property to a different "Save(Store item)" event that performs logic and adds the item to a repository.

I hope this feedback helps you guys out.
Jan 26, 2007 at 1:48 AM
Hey buddy,

It´s VERY GOOD to know that you (as I am) are using the framework for real applications.

I see your point and I´ll clarify it for you.
What you are trying to achieve isn´t really the MVP pattern (one presenter bound to a view). It´s the Composite MVP pattern (multiple presenters, bound to multiple views). This is a much more complex pattern and in fact it´s the reason why this framework came out. I´ll probably be posting a sample of how to use the framework to implement something just as what you just described.

The basics are:
Host - That´s your web page that will host every child view.
HostPresenter - That´s the guy that orchestrates the Host and calls on every single presenter that is enlisted in initialization.
Container - That´s the one that keeps track of what has changed and calls the appropriate Save method in each item in the list.
ContainerItem - This guy is every single row of the container.
ContainerPresenter - That´s the guy that orchestrates the items.
Presenter - This is your old fella, which is responsible (in this case) for saving ONE and only ONE row. So for each row the save method in each presenter (bound to that row) will get called upon.

I hope that the sample will help you clarify this toughts.

There are a lot of new stuff coming for ASP.Net. Keep track!

Bernardo Heynemann