Link to home
Start Free TrialLog in
Avatar of brettr
brettr

asked on

Does MVP and MVVM have any value?

Microsoft .NET programming can involve lots of design patterns in a single app.  Two that I hear much about but never see implemented are MVP and MVVM.  The only people I see implementing these patterns are the ones putting together examples of how to use them.  Which says to me they have no value.

My question is: Do you see any value in these two patterns and why?

Even listening to the experts, they have a difficult time describing these patterns and what use they are.  In the real world, I've never seen an app that is only data binding straight from the DAL (MVP) without some additional logic to filter data into objects and then bind those objects through a more complicated process.

Environments such as Cocoa and Cocoa Touch use MVC.  Ruby on Rails has a setup that guides you into a single design pattern.  It's easy to talk about these environments and they're patterns because they are explicit.  .NET on the other hand is like a mutt where people string together all sorts of patterns into a single app.
Avatar of abel
abel
Flag of Netherlands image

(this question might be better suited in the Patterns zone)

If you are looking for some explanations on the differences between MVP and MVC, this link: http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html might help you out.

I'm not sure what you mean when you say "never see it implemented", as MVP is all around us. You cannot make a single web application using Visual Studio + .NET while using MVP. You can of course discuss up to what level the MVP is implemented by ASP.NET / WinForms, but it's there and it has been there for a very long time.

When you say that "people string together all sorts of patterns into a single app" it sounds like you are referring to projects you have seen and that it's a bit like a bunch of everything and that it's hard to clearly distinguish certain patterns in real world applications made by developers using .NET environments. That's not a problem with .NET, but a problem with the people using it, who often don't have the slightest ideas of the underlying concepts and mess around and place controller-code in the presenter layer and vice versa: no separation of concerns with beginners, but that's why they are beginning programmers. And the Microsoft world just has on average a bit more beginners around then any other world...

Using a single design pattern is something you will hardly ever encounter in real life (you say you do, but are you sure about that?). Not if you use Ruby on Rails, not if you use Objective-C and Cocoa, not if you use Cocoon (Apache's MVC container, can also be used as MVP iirc) or if you use the MVP-enabled frameworks coming with Microsoft's products. That's because design patterns are not meant to solve all application needs, they solve one (of many) application needs.

In any given application, I find it very common to see the Singleton pattern (actually, it's hardly ever absent) and it's thread-safe derivatives, the Factory pattern (can't do without it whenever I'm abstracting my DAL/DAO/ORM), the Proxy pattern (whenever I interface to an alien/3rd party interface), the Decorator pattern (the new concept of .NET's extension methods can even be seen as a decorator pattern "the easy way") and the MVP/C patterns (any XHTML + CSS is in fact an (partial) example of this already, but normally we mean the larger frameworks that help us separate the logic). Should I go on? These are only GoF patterns (MVP/C excepted).

Your question whether I see any value in these: yes, I do. Why? Because I cannot work without them (lousy answer, huh?) , or, basically, since for a decade I have been working almost exclusively in MVP-like designs, with some sidesteps to MVC. Both are very intuitive once you get the hang of it and help you keep the separation of concerns clear.

-- Abel --


I just came across a pretty basic post on CodeGuru, which frowns upon using MVC with ASP.NET (or WinForms for that matter), simply because the .NET platform is more geared towards an MVP (which is probably why I usually see MVP around and not MVC when I work on .NET projects): http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173 
Avatar of brettr
brettr

ASKER

Thanks for the great info.  Once codeguru.com gets their site back up, I'll check it out.

From the first link you provide, it mentions an MVP Passive View.  But when you go here http://martinfowler.com/eaaDev/PassiveScreen.html, it seems as though Fowler is discussing Passive View as an alteration of MVC rather than MVP.  He never really calls Passive View a modification of MVP.  He just says, "...in the classic MVP movement".  Do you know which pattern Passive View follows - MVP or MVC?
Well, the simple answer to that is (not sure you'll like it): both. The passive view from Fowler, for as much as I understand it, can be considered an alternative to either of them. If you take his introduction line on the link you just posted, he says so himself:

This pattern is yet another variation on model-view-controller             and model-view-presenter
which is closely to how I understand it. Note that MVC is a very old pattern. MVP is a derivative of the MVC, it just twists the roles around a bit to make it versatile for the event driven model. Any derivative from MVP is automatically a derivative of MVC (but not necessarily each derivative of MVC is also a derivative of MVP... ).
Avatar of brettr

ASKER

Thanks.

So MVP basically came about as a result of Windows event driven model and similar such event driven apps?

If that is the case, I agree with you that MVP is everwhere since virtually all apps are event driven.  Yet, many developers say MVC.

Do you believe ASP.NET is really MVC?  MVC seems so outdated and limited.  Is it that they are really doing MVP?
There's a lot of misunderstanding going about MVC and MVP. The largest perhaps being that many people say they are using technology X while they are actually using technology Y without knowing, or simply because they want to show off somehow.

The problem with these patterns is, that in my experience, there are very few people that grasp the hidden complexity of the separation of concerns (which lies at the basis of both MVP and MVC) and the benefit that's reached when applied correctly.

I've seen many projects and many buzztalk about patterns. Clearly, in most cases where you enter the event driven world, you are looking at an MVP pattern.

ASP.NET is, imo, an MVP architecture, but this is not really an is-a relationship. But, because it is a very generic framework, it doesn't force MVP on you. Which is why so many websites have controller-code right in the ASPX or business logic layers mixed with HttpContext-code to "talk back" to the website, but in reality, they just don't know how to properly use MVP with ASP.NET.
I haven't tried this myself, but there seems to be a project that tries to help you a bit further with the MVP-enforcement on the ASP.NET front: http://www.codeplex.com/aspnetmvp
Avatar of brettr

ASKER

Thanks again.  Last link is good info.

How does "is-a relationship" factor into decisions about MVC vs MVP?  is-a relationship is used for inheritance vs composition/aggregation.
Avatar of brettr

ASKER

And just to clarify, Presenter in MVP is really Controller in MVC?
ASKER CERTIFIED SOLUTION
Avatar of abel
abel
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of brettr

ASKER

Big thanks for so much info.
You're welcome, glad I could be of some guidance ;)