MVP question

  • Thread starter Thread starter Steve K.
  • Start date Start date
S

Steve K.

I'm using Model View Presenter for my UI, I like to structure it introduces
and it tends to make me "do the right thing"

One problem I'm having is making the distinction between what I can and
can't do in the View code. For example if a user modifies a value in the
View and I want to change an icon somewhere on the View is it good form to
handle that change in the View code or should I do something like:
<Value in View field changes>
this._icon.Image = _presenter.GetImageForItem(item);

Basically, shoud I run all changes through the presenter?

Another question:
I have a View with many fields (20+). When I finally want to save the data
by giving it to the Presenter for instinct is to instantiate one of my
Business Objects, set all the properties then send this instance to the
Presenter. It's just *feels* cleaner, but I think I'm breaking MVP by using
a Model instance in the View, no?

The alternative would be a method like this:
_presenter.SavePatient(string fName, string mInitial, string lName,
string address1, string address2, int cityId, int stateId, string
zipCode,
string physicianFName, string physicianMInitial, string physicianLName,
string physicianAddress1, string physicianAddress2, int physicianCityId,
int physicianStateId, string physicianZipCode, etc, etc, etc);

That makes mt stomach turn! ;0)

But.... it might be proper MVP, I don't know. What do you all think?

-Steve
 
Steve... IMHO, a view component can have state and logic related to its
purpose.
It is not possible to answer the question without knowing who "owns" the
icon.
If the icon is part of a specific view component, say a charting
component, then
the view component probably should probably set the icon property
directly.
This is in keeping with a "separation of concerns."

I would favor passing an immutable object or structure from the view to
the
presenter. The presenter can then validate and pass the validated object
or
structure to the Model for persistence.

Regards,
Jeff
 
Steve K. said:
I'm using Model View Presenter for my UI, I like to structure it
introduces and it tends to make me "do the right thing"

One problem I'm having is making the distinction between what I can and
can't do in the View code. For example if a user modifies a value in the
View and I want to change an icon somewhere on the View is it good form to
handle that change in the View code or should I do something like:
<Value in View field changes>
this._icon.Image = _presenter.GetImageForItem(item);

Basically, shoud I run all changes through the presenter?
Click to expand...

It should be done with UI code and not View code IMHO.
Another question:
I have a View with many fields (20+). When I finally want to save the
data by giving it to the Presenter for instinct is to instantiate one of
my Business Objects, set all the properties then send this instance to the
Presenter. It's just *feels* cleaner, but I think I'm breaking MVP by
using a Model instance in the View, no?
Click to expand...

You use the interfaces between the UI and the Presenter/View, with the View
working with the Bus_object/Model. The UI should be unaware of the
Bus_object/Model. If the UI knows of the Bus-object/Model, then you have
broken the concept of MVP with tight coupling of the UI to the
Bus-object/Model - a no no.
The alternative would be a method like this:
_presenter.SavePatient(string fName, string mInitial, string lName,
string address1, string address2, int cityId, int stateId, string
zipCode,
string physicianFName, string physicianMInitial, string physicianLName,
string physicianAddress1, string physicianAddress2, int
physicianCityId,
int physicianStateId, string physicianZipCode, etc, etc, etc);

That makes mt stomach turn! ;0)
Click to expand...

Do you know what an interface is about?

You pass the data through interfaces, that are on the Presenter/View. You
invoke the Save() method on the Presenter/View from the UI through the
interface.

The Presenter/View instantiates the Bus_object, and the Presenter/View
populates the Bus-object via its interfaces.

The Presenter/View.Save() invokes Bus_object.Save method.

The Bus_object.Save instantiates the DAL-object, and it populates the
properties of the DAL-object with like properties of the Bus-object.

The Bus-object.Save invokes the DAL-object.Save method.
But.... it might be proper MVP, I don't know. What do you all think?
Click to expand...

You reverse the order when bringing data back. And sometimes, you don't use
a Bus_object collection and bring it back up to bind to a control like a
Datagrid. You being a Datatable back through the interface when possible, as
an example. But not using Bus_objects is not a rock hard it has to that way
rule either, when binding data to a control at the UI via a Presenter/View
interface.


MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5
 
Back
Top