tag:blogger.com,1999:blog-8397311766319215218.post3692111420290486675..comments2023-11-29T18:05:17.337+01:00Comments on metablog: Model Widget Controller (MWC) aka: Apple "MVC" is not MVCMarcel Weiherhttp://www.blogger.com/profile/11651004661887001433noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-8397311766319215218.post-52494938140722827802023-11-29T17:48:54.244+01:002023-11-29T17:48:54.244+01:00Apple's MVC is not really Model, View Controll...Apple's MVC is not really Model, View Controller, it actually means "Massive View Controller", which is what happens when you try to trick developers thinking this widget is actually part of the architecture MVC. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-39734123409451765382016-03-05T01:12:04.692+01:002016-03-05T01:12:04.692+01:00I recommend watching an 'uncle bob clean archi...I recommend watching an 'uncle bob clean architecture' video<br /><br />To summarise the parts relevant to your post:<br />1) MVC and the like are GUI patterns not application architectures, and as such are a minor architectural concern<br />2) The MVC pattern was originally intended to be implemented many times for each tiny GUI component - button, field or label, where the 'model' is the model of that button, field or label.<br /><br />The conclusion is that there shouldnt be any huge concern about a particular flavour of MVC/MVP or whatever that you use for you GUI pattern, but because people are confusing it with the architecture for their entire application - banging square pegs into round holes - they are magnifying the minor differences into undeserved and undesirable importance.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-6107550223825010662016-01-25T17:19:40.340+01:002016-01-25T17:19:40.340+01:00Just wanted to say apple actually acknowledges the...Just wanted to say apple actually acknowledges the existence of the "traditional" version (complete with references to the design patterns!) in their <a href="https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html" rel="nofollow">docs</a> and provides a justification for their Cocoa version.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-83427869615914038352015-08-24T01:51:23.205+02:002015-08-24T01:51:23.205+02:00@John Daniel
regarding this:
"But on second...@John Daniel<br /><br />regarding this:<br /><br />"But on second thought, you would probably have better luck reforming Apple's nomenclature than you would improving the architectural practices of the app developer community. People are confused and Apple doesn't really help with that. <b>Arguing over names doesn't help either."</b><br /><br />I'd strongly argue that this kind of writing about these issues really does help others coming at these things from a more theoretical and stunted point of view. It certainly helps me.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-54822856854577097972015-04-07T13:19:00.873+02:002015-04-07T13:19:00.873+02:00Good luck wresting the power to name from the worl...Good luck wresting the power to name from the world's most powerful corporation. Smalltalk is dead. Get used to it. <br /><br />As for the "Massive View Controller", I was on a plane this weekend and watched a couple of WWDC videos on architecture. It turns out that Apple doesn't promote that idea at all. See "Core OS iOS Application Architectural Patterns", session 224.<br /><br />Obviously most developers just copy and paste from sample code and StackOverflow instead of watching WWDC videos. They rarely consider things from an architectural standpoint and that is what leads to API soup and "Massive View Controller". <br /><br />But on second thought, you would probably have better luck reforming Apple's nomenclature than you would improving the architectural practices of the app developer community. People are confused and Apple doesn't really help with that. Arguing over names doesn't help either.John Danielhttp://etresoft.comnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-4824422170213992802015-04-05T14:29:31.894+02:002015-04-05T14:29:31.894+02:00What I've always liked about Apple's versi...What I've always liked about Apple's version of MVC is that I seldom subclass View objects as they don't need to know anything about the M or, for the most part, the C.<br /><br />I also never restricted Controllers to only being view controllers. You can split logic up amongst many controller objects (data controllers, network request controllers, ...) and I don't find my controllers getting unnecessarily large and complicated.<br /><br />Remember that with Smalltalk, we programmed by changing the environment - the patterns we use will change depending on the language and the framework we are coding for.<br /><br />The patterns I use in Swift are very different than the patterns I use in Obj-C even though I'm working with Cocoa and Cocoa Touch in both.Danielnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-57780647269568761902015-04-05T05:29:27.866+02:002015-04-05T05:29:27.866+02:00Check this article from Matin Fowler: http://marti...Check this article from Matin Fowler: http://martinfowler.com/eaaDev/uiArchs.htmlNorberto ortigozahttps://www.blogger.com/profile/01302273618528020253noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-855092251867074322015-04-05T00:01:21.727+02:002015-04-05T00:01:21.727+02:00MVP and MVA are kind-of the same. The Controller m...MVP and MVA are kind-of the same. The Controller mediates between the model and the view, instead of the classic Smalltalk triangle, where the view knows about the model.<br /><br />The advantage of MVA/MVP is mainly the highly decoupled state and reusable components: models and views are all reusable independently. In classical MVC, the view most often cannot be reused for completely different models.<br /><br />The disadvantage of MVA/MVP is that you need more glue to glue all those reusable components together. That glue tends to end up in the Controller. Whenever you implement a UITableViewDataSource in a ViewController, you are glueing together your model and and the re-usable view. <br />Classical MVC doesn't really have that disadvantage at all: since the view gets data from the model directly, the controller doesn't need to glue those two together.<br /><br />The problem with Apple's MVC in UIKit is that more and more of that glue is needed with every major iOS release, and thus ViewControllers become bigger and bigger. Things such as viewDidLayoutSubviews, updateConstraints, top/bottomLayoutGuide should all be done by the view. When is the last time you implemented -loadView, instead of creating a bunch of subviews in -viewDidLoad? Creating subviews should be part of the View logic, but often ends up in the ViewController.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-71684532639043431002015-04-04T23:38:53.865+02:002015-04-04T23:38:53.865+02:00Marcel, how do you solve the Massive View Controll...Marcel, how do you solve the Massive View Controller problem with the pure or original MVC? Is a ViewController part of the View in that thinking? Maybe I should look at the source material. Anyhow, coupling view and model seems bad. Maybe MVVM to the rescue? Any thoughts on that?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-4883349742366268442015-04-04T16:57:38.301+02:002015-04-04T16:57:38.301+02:00Thanks for your comments!
@Anonymous: Hmm...my f...Thanks for your comments!<br /><br />@Anonymous: Hmm...my first guess was Model View Presenter (Taligent, Dolphin Smalltalk), though MVA sounds very similar.<br /><br />@Adam: Yes, nightmarish controllers are the common problem with MVP, which is why Apple's version has been called "Massive View Controller". Actual MVC can have very slim controllers.<br /><br />@John: Pardon my bluntness, but if you envision MVC to be this, you envision wrong. It may very well be that the pattern you prefer (MVP/MVA) is better than MVC, but it's a different thing and has a different name. And yes, you can swap out the View for a command-line test rig in classic MVC, because the Model does not know about the View.<br /><br />MVP/Massive View Controller tends to end up with much of the code in the "ViewController" (whatever that is supposed to be), which then happens to be coupled to both the views and the model.<br />Marcel Weiherhttps://www.blogger.com/profile/11651004661887001433noreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-54059983872654740422015-04-04T14:44:25.042+02:002015-04-04T14:44:25.042+02:00I don't think I ever really understood MVC unt...I don't think I ever really understood MVC until I worked with the PHP Zend framework (version 1, not 2). I think my problem was that Apple kept confusing me. However, I don't have a problem with this particular Apple diagram. This is the way I envision MVC to be. I don't really care who had the original diagram. I am comfortable with the idea of having the MVC concept evolve to match expectations and usability. From that perspective, Apple's diagram where the model and view are decoupled is what I expect. I want to be able to swap out the UI view for a command-line test rig, for example. I want to swap out the local model for a cloud model. I don't fault Apple on its diagrams, but its implementations. To say you implement MVC and then have a whole suite of classes named "ViewController" is just ridiculous. Which is it? A view or a controller? Apple's approach leads to an API soup and a bunch of code that gets in the way of application logic. But the diagram itself - I like that. I just wish Apple's code and architecture followed its diagrams.John Danielhttp://etresoft.comnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-90897852058032756552015-04-03T23:04:25.383+02:002015-04-03T23:04:25.383+02:00What Apple uses as MVC is often called the Model–V...What Apple uses as MVC is often called the Model–View–Adapter variant. The Controller mediates between the View and the Model and adapts model data to view representations and view interaction to model changes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8397311766319215218.post-3932251885547528202015-04-03T20:21:26.446+02:002015-04-03T20:21:26.446+02:00This is news to me, since I learned Apple's no...This is news to me, since I learned Apple's notion of MVC from the Cocoa documentation. In an NSDocument-based application I've worked on (BibDesk), our model communicates only with the document (except for a few NSNotifications). This has worked out fairly well, insofar as we have changed the views out with little difficulty. The document (controller) is a nightmare, though.Adam R. Maxwellhttps://www.blogger.com/profile/14544244685304728869noreply@blogger.com