Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / January 2008

Tip: Looking for answers? Try searching our database.

MVP question

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Steve K. - 13 Jan 2008 01:38 GMT
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
Jeff Louie - 13 Jan 2008 05:54 GMT
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
Mr. Arnold - 13 Jan 2008 08:35 GMT
> 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"
[quoted text clipped - 7 lines]
>
> Basically, shoud I run all changes through the presenter?

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?

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,
[quoted text clipped - 6 lines]
>
> That makes mt stomach turn! ;0)

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?

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

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.