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...
There 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.
I 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.
a) 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.
Isn't the controller where your bussines rules are encoded? It is probably the more complex part of your app, and it's complexity is driven by business decisions and not technical ones. Unless you mean something different by controller(very possible, it is a very overloaded term), I don't think your premises are very sound.
I think this gets to the heart of this discussion. Since the term 'controller' is so vague everybody has a different understanding.
In iOS development there are UIViewControllers which are very tightly coupled to the UI, but are often misused to handle business logic.
With MVVM you essentially treat them as views and extract everything that is not exclusively related to visual presentation.
I see the controller as an objects whose purpose is to shuttle data back and forth between the view and the model. The business rules should be in the model. the controller can do some very minor formatting type things, handle events, etc. but no business rules.
Basically, the View is presentation, the Controller is interaction and the Model is logic and data.
Yeah, in that case I agree with you. Under that definition M-VC just means to separate your business rules from your UI, which is always a wise move. I do think the interesting part that is missing is how you organize everything that isn't UI, but I guess that's a topic for another discusion.
> 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.
A 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?
IMO, 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.
MVC 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.
This whole debate about mvc vs mvvm vs i don't know what really start to read like a joke.
Here's the truth : your app probably has more than three major components, and the GUI isn't the most important aspect of it. Build your app as if it was to be accessed through a command line or a repl, then add a GUI on top in the end.
You'll have reusable, business centric components, and your controllers ( or whatever you call it) won't be bloated.
Yes, exactly. In ASP.NET MVC land, our our general convention is to have a service layer that does all of the business logic, and the actual MVC web layer only handles UI concerns.
In theory, you set your service layer (just a class assembly) up so that it can handle requests from multiple UI layers (a web MVC layer, a phone app, or even one case, a command line prompt).
Yes indeed. Backend developpers have known "services" layer for a long time, but it seems to be completely unknown to frontend developpers (except maybe angular ones, which heavily promotes this pattern).
Model is basically a collection of types, and services are where the business happen and shit gets done. And only in the end should you care about presenting all that stuff in a good looking way.
But even this is a bit of a simplification once you get into low-level architectural decisions : is your app real time, does it handle data synchronization with a backend, can it work online and offline , does it need to make certain operations atomically ? Do you have n publisher - n subscribers types of communication between your components ? etc etc.
Those are the true questions you need to ask yourself first, and not think in terms of three or four big boxes where you have to put all your junk trying to find descent names.
Well, if I restrict my scope to the rich web client ("SPA") style work I have mostly been doing for a bit over a year, it is. In fairness, that's because there is a back end with all of the "real" business logic in it, and I just put up what the view-model tells me to, wiring buttons and some other events to REST calls to phone home and find out what to do next.
Anyway, you are usually right, but the project type matters: there might be just enough UI to enter some selection bounds and then kick off a batch process, or it might be a small game that is little more than a "busy box" consisting almost entirely of pretty artwork and responses. Plan & budget the design effort for the UI accordingly.
Not necessarily. This could all be accomplished just be decoupling the view from everything else. It doesn't have to conform to MVVM, MVC, MVP, MVWhatever.
The part you're missing is that there is a huge grey area between 'model' and 'view'. So large in fact that all of these patterns where designed solely to help you draw lines in the sand between the pieces.
I don't disagree with what you're saying. But there are patterns where there's the View and ... everything else. It's a perfectly valid way of organizing code (for, admittedly, simpler code bases).
If you're using storyboards, another way of solving this is to let your segues set up the view models of the source and destination view controllers. You just need to create some segue subclasses for each source/destination combo you need.
Better than polluting prepareForSegue, and it totally decouples your UIViewControllers from each other. The coupling is in the segue, which is where it should be.
I work in an MVVM mode daily. The best MVVM frameworks help bootstrap the app shell, but require zero interfacing with the view afterwards, with the 'controller' just being a parent ViewModel. It's turtles all the way down.
Is it ok if I ask about something totally unrelated to the article? I was wondering, for the hotel booking companies that Trivago collects data from, do you have an agreement with them about it? Do they pay anything to you, or you pay anything to them, or neither? Does Trivago make any money? If so, how?
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...