Practical Benefits of MVC or MVP Patterns

[Jeff S]

Okay, I just finally figured out the Model View Presenter pattern as
presented by Martin Fowler
(http://www.martinfowler.com/eaaDev/ModelViewPresenter.html). I even got a
small model of it working in a Windows Forms app I created from scratch.
Pretty cool how the form is sitting there and gets populated from the
Presenter - and the Form is pretty dumb (i.e., it really has no clue where
it's getting populated from.).

I understand that creating a "dumb" UI layer (per MVP and similar patterns)
has the benefit of allowing us to have multiple forms that all get populated
from the same Presenter. Great. What if I have no intention of ever doing
that (i.e., I have good reason to think I'll never have multiple screens
presenting the same model/data; or I'll likely never be providing both a Web
UI and Windows or Mobile UI). Should I still implement MVP or some other
means of separating the UI (Form) from the underlying data?

Please understand that I already know the answer is likely "yes, of course
you should separate it all out."

But what I would really appreciate are some specific benefits of doing such
separation and concrete examples if possible (reasons beyond the theoretical
"if you ever need to it will all be ready to go.").

Thanks for your time and consideration.

-Jeff

 

[Guest]

Hi Jeff,
no example here but the nice benefit of this pattern is that because your
UI is mainly dumb and the bulk of your code lives inside the controller and
model it makes your code easier to unit test. Because the controllers are
just classes they can be unit tested just like any other class, the more
code you have in the GUI the more you have to test through the GUI which is
difficult, you either have to do it by hand or use some kind of script
generator like Rational Robot, both of which are tedious for regression
testing.

If you are not unit testing your code though then you will obviously not
get the benefit from this. We do this at the place where I work, so it is
not just a theory but I have seen real benefits. On of the first pieces of
code I had to work on all the logic in the GUI and it was virtually
impossible to automate the testing.

My 2 cents

Mark
http://www.markdawson.org

 

[Lloyd Dupont]

Hi Jeffs,

Generally this kind of stuff requires more work for the conception of the
control, but give it more flexibility or tweakability shall I say.
So if it is just for 1 end user screen, don't bother.
The only time I found usefull to have a "presenter" was for my custom
textview in C#. all text layout / drawing / etc... is handled in the
DocumenUI class. That way I could reuse the layout/etc code for a credit
control, a PrintDocument, etc...

For simple, no brainer or very unique (i.e. not likely to be reused) drawing
task, this is a tad overkill.....


--
Regards,
Lloyd Dupont

NovaMind development team
NovaMind Software
Mind Mapping Software
<www.nova-mind.com>

 

[Joanna Carter [TeamB]]

"Jeff S" <[email protected]> a écrit dans le message de (e-mail address removed)...

| Okay, I just finally figured out the Model View Presenter pattern as
| presented by Martin Fowler

This article doesn't really talk about the "proper" MVP pattern; it seems to
be a slightly more sophisticated MVC pattern.

I have written a complete MVP pattern for Delphi and you can see the
articles on my site : www.carterconsulting.org.uk

| I understand that creating a "dumb" UI layer (per MVP and similar
patterns)
| has the benefit of allowing us to have multiple forms that all get
populated
| from the same Presenter. Great. What if I have no intention of ever doing
| that (i.e., I have good reason to think I'll never have multiple screens
| presenting the same model/data; or I'll likely never be providing both a
Web
| UI and Windows or Mobile UI). Should I still implement MVP or some other
| means of separating the UI (Form) from the underlying data?

Whether you use MVC/P or any other pattern, it really does help your sanity
and the future maintainability of your code.

| Please understand that I already know the answer is likely "yes, of course
| you should separate it all out."

See, I told you so )

| But what I would really appreciate are some specific benefits of doing
such
| separation and concrete examples if possible (reasons beyond the
theoretical
| "if you ever need to it will all be ready to go.").

Let me know if my articles help.

Joanna

 

[Charles Law]

Hi Jeff

You could also look at this from the other direction. By keeping the
presentation separate, it doesn't just allow you to add another viewer to
your data. It also allows you to reuse your presenter, since anything that
complies with the interface can be presented in the same way, so you can
have a generic viewer for all your data.

HTH

Charles

 

[Nick Hounsome]

I totally agree with Mark.

I would also add:

* It is easier to understand when maintaining it because the roles are
divided up better.
* I seem to remember a refactoring tool that made pulling interfaces out of
classes trivial but I can't remember where I saw it (not in VS2005 express)