I was hoping this article would resolve something that I have been curious about. MVP (Model View Presenter) has been in vogue in the GWT world lately, as a result of Ray Ryan's seminal Google I/O presentation in 2009 and all of the open source projects spawned by it that attempt to reify the patterns therein (one of which is MVP).
As presented by Ray, the diagram of MVP shows that the view never speaks directly with the model object, and always uses the presenter as an intermediary.
I wonder, what is the difference between this idea and how MVC is practiced in the Cocoa universe? The present article talks about how it (Cocoa) uses the mediator pattern to accomplish the same thing.
Look, for example, at the diagrams in the fairly famous Stanford CS193P lectures: (the Lecture 1 PDF at the top of the following page)
If you go to page 38 in the slides, or therabouts, you see a fully dressed-out diagram of how MVC is practiced in iOS, including all of the various communication mechanisms that the view uses to get to the model via the controller as a mediator. (Even the event bus, NSNotificationCenter, is used as a channel between the model and the Controller - not between the model and the view. Same with KVO.)
Incidentally, there is a Stack Overflow question discussing this very conundrum, and I don't feel that any of the current answers are very compelling.
To me, Cocoa MVC smells like MVP. The current Wikipedia entry on MVP isn't very helpful. It seems to focus more on the pattern's history in .NET (and, before that, Taligent).
Having experience with winforms and Cocoa development, I have to vouch for the slickness of Cocoa MVC vs what usually happens with Winforms and event driven development.
I've never found a consistently better OO API than Cocoa (that survived any amount of time). It's a great evolution of the NeXTStep frameworks, which were mentioned allover the GoF book.
That is true- and I really like WPF/MVVM. Im also pretty impressed with ASP.NET MVC. However until recently there was not significant WPF traction for desktop applications. I really feel that one of cocoas best features is its simplicity. Its logical, powerful and easy to learn. I think WPF/MVVM may have a slightly steeper learning curve.
However until recently there was not significant WPF traction for desktop applications.
I'd argue there still isn't much traction for WPF. And based on Win8 rumors it sounds like MS is going to go all in on Silverlight. My bet is that WPF is their interop framework (because it works much better with legacy native apps) and Silverlight is where you do everything else.
WPF does have a decently steep learning curve, but it pays you back with interest.
was introduced to MVC by Django, and today it is by far one of my favourite pattern to use in every app/framework that i write ground up. if used correctly, it decouples dependency beautifully, and allow domain experts to work on their area of expertise.
some people might disagree with my belief that domain experts should be focused on their task at hand given the uproar and hype about scrum which i seriously disagree with: of which everyone shares everyone else's code responsibility.
http://www.google.com/events/io/2009/sessions/GoogleWebToolk...
As presented by Ray, the diagram of MVP shows that the view never speaks directly with the model object, and always uses the presenter as an intermediary.
I wonder, what is the difference between this idea and how MVC is practiced in the Cocoa universe? The present article talks about how it (Cocoa) uses the mediator pattern to accomplish the same thing.
Look, for example, at the diagrams in the fairly famous Stanford CS193P lectures: (the Lecture 1 PDF at the top of the following page)
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/download...
If you go to page 38 in the slides, or therabouts, you see a fully dressed-out diagram of how MVC is practiced in iOS, including all of the various communication mechanisms that the view uses to get to the model via the controller as a mediator. (Even the event bus, NSNotificationCenter, is used as a channel between the model and the Controller - not between the model and the view. Same with KVO.)
Incidentally, there is a Stack Overflow question discussing this very conundrum, and I don't feel that any of the current answers are very compelling.
http://stackoverflow.com/questions/353646/design-patterns-fo...
To me, Cocoa MVC smells like MVP. The current Wikipedia entry on MVP isn't very helpful. It seems to focus more on the pattern's history in .NET (and, before that, Taligent).
http://en.wikipedia.org/wiki/Model_View_Presenter
Does anybody have any thoughts on this?