
A short introduction to the MVVM-C design pattern - andygrunwald
http://tech.trivago.com/2016/08/26/mvvm-c-a-simple-way-to-navigate/
======
w0utert
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...

~~~
Stengo
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.

~~~
JustSomeNobody
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.

[0] There are exceptions to everything.

~~~
Fargren
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.

~~~
JustSomeNobody
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.

~~~
Fargren
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.

------
bsaul
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.

~~~
mason240
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).

MVVM-C seems overly complicated.

~~~
bsaul
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.

------
afro88
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.

------
currywurst
A relevant previous HN discussion on Martin Fowler's "GUI Architectures"
article
([https://news.ycombinator.com/item?id=9770362](https://news.ycombinator.com/item?id=9770362))

------
achr2
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.

------
omn1
trivago standing by to answer your questions :-)

~~~
eriknstr
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?

~~~
omn1
Sure. We have agreements with our partners. Here's a pretty good explanation:
[https://www.quora.com/How-do-metasearch-vertical-search-
engi...](https://www.quora.com/How-do-metasearch-vertical-search-engines-like-
Otalo-and-trivago-make-money-Why-would-companies-give-them-access-to-their-
Apis-if-theyre-going-to-be-taking-a-percentage-off-the-top)

~~~
eriknstr
Thanks :)

------
HelloNurse
s/Coordinator/Controller/g

