4 ms·
This article addresses some interesting, real-world problems with the MVC pattern, problems I've run into myself. When writing iOS applications I also usually e
by w0utert 10y ago
This article addresses some interesting, real-world problems with the MVC pattern, problems I've run into myself. When writing iOS applications I also usually end up with something that is better described as M-VC than MVC, where the view and the controller are tightly coupled and usually implemented by the same class. This is not how the MVC pattern was intended.
From a cursory read I like the architecture improvements they propose to 'fix' this situations. That said, I can't escape the feeling that for the majority of applications, this is way over-designed/over-engineered, and putting the cart before the horse. Your application should not be written to better suit the MVC (or MVVM-C) pattern, it should be the other way around. Often a merged VC class gets the job done just fine and keeps things simple and concise.
In my experience, my own applications end up with a single class that's both the view and the controller, for the simple fact that there is no reason to decouple them. I'm usually not interested in having multiple user-interfaces on top of the same model, so there is no incentive to re-use the controller. Note that IMO there is a clear distinction between decoupling the model from the view and/or controller (which is almost always desirable to separate data and presentation), and decoupling the view from the controller (which have a lot of overlapping resposibilities)
To be fair, I haven't written any applications that hat different UI for e.g. iPhone and iPad, and I haven't written any applications that also have a desktop counterpart. But even in those situations, I'm wondering how much there is to be gained from re-using controllers for different user interfaces...
- JustSomeNobody 10y ago> When writing iOS applications I also usually end up with something that is better described as M-VC than MVC, where the view and the controller are tightly coupled and basically the same class. This is not how the MVC pattern was intended. No, but if M-VC works, then it's fine. MS used Document/View architecture where the View was decoupled from the Document (model) in MFC and that was very popular and successful for years. "The humble dialog", IIRC, describes something similar. I don't think we developers should fear the wrath of the the MVC police if we choose not to decouple everything.
- stcredzero 10y agoA lot of the codifying of MVC happened in Smalltalk. However, the reality of Smalltalk development is that most people had Model objects, then stuck everything into instance slots of an instance of an "ApplicationModel" subclass. Originally, ApplicationModel was called "GluePuppy" because it was just an arbitrary thing on which to stick other things. So who in the world are these MVC police? Does anyone in the world actually do MVC correctly? Has anyone ever?
- Stengo 10y agoThere are essentially two problems with combining the view and the controller: a) Writing tests for the combined class is incredibly hard. Since you are relying on the UI framework to call your code you have very little control over when something happens (and what side effects it will cause). b) Changing your code becomes a lot more time consuming. In an agile environment you want to be able to quickly change behavior and looks (sometimes even on the fly) which gets harder the stronger your coupling is. The goal of MVVM is essentially to have extremely 'dumb' views that do nothing but relay data between model/logic and the UI.
- w0utert 10y agoI do understand there are some benefits, but I'm not convinced they outweigh the disadvantages (increased complexity, more code to glue everything together, which almost by definition increases the risk of breaking things). >> a) Writing tests for the combined class is incredibly hard. Since you are relying on the UI framework to call your code you have very little control over when something happens (and what side effects it will cause).* While this is definitely true, I fail to see how separating controllers and views helps to improve the reliability of your user interface code. Yes, it makes it easier to test individual parts of your UI code independently and without side-effects, but eventually all of it will end up on a user's device (that's the assumption, at least ;-), which means it has to 'rely on the UI framework' and 'has very little control over when things happen' anyway. If you are concerned about testing isolated parts of the UI code without side effects, it's probably better to factor them out into functions and test those directly. >> b) Changing your code becomes a lot more time consuming. In an agile environment you want to be able to quickly change behavior and looks (sometimes even on the fly) which gets harder the stronger your coupling is. I totally agree with this, but the question remains how many application developers face this scenario, and how the flexibility/complexity tradeoff scales for moderately complex user interfaces.
- JustSomeNobody 10y agoa) Your controller should be relatively simple. If it is buggy/broken it should be immediately obvious when the app is run. So, not being able to unit test it separately is not a big a deal, I think[0]. b) I don't think having the view and controller coupled makes this a big deal in a lot of cases[0] as long as the controller doesn't have behavior creep. [0] There are exceptions to everything.
- bryanlarsen 10y agoIMO, 90% of so-called 'MVC' applications are actually MV applications. In a typical Rails application (or one of the myriad frameworks inspired by rails), the code in 'controllers/' is actually view code that happens to be written in Ruby rather than in the template language of choice. The controller is actually in config/routes.rb. But as you mentioned, this is actually a good thing for most Rails apps. If your app doesn't need a controller, putting a controller in is just over-engineering.
- tamana 10y agoMVC for the web was basically taking MVC for the (Mac) desktop, where it was invented and made sense, and slapping the name on something different because Rubyists love Macs.