10 ms·

A short introduction to the MVVM-C design pattern

56 points by andygrunwald 10y ago

omn1 10y ago
trivago standing by to answer your questions :-)
- eriknstr 10y ago
  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 10y ago
    Sure. We have agreements with our partners. Here's a pretty good explanation: 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 https://www.quora.com/How-do-metasearch-vertical-search-engi...
    - eriknstr 10y ago
      Thanks :)
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 ago
    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?
- Stengo 10y ago
  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.
  - w0utert 10y ago
    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.
bsaul 10y ago
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.
- _pmf_ 10y ago
  So, you're proposing MVVM.
  - JustSomeNobody 10y ago
    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.
    - achr2 10y ago
      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.
      - JustSomeNobody 10y ago
        I would argue there's a grey area between the 'view' and the 'controller', but not the 'model' and the 'view'. The model is logic and data and has absolutely nothing to do with presentation. But, I will concede there are 1001 ways to interpret these patterns (MV*).
        achr2 10y ago
        Agreed - however, I wrote 'model' considering the binary separation that was suggested.
deleted 10y ago
[deleted]
HelloNurse 10y ago
s/Coordinator/Controller/g
currywurst 10y ago
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 10y ago
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.
afro88 10y ago
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.

56 points by andygrunwald 10y ago

omn1 10y ago

trivago standing by to answer your questions :-)

eriknstr 10y ago
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 10y ago
  Sure. We have agreements with our partners. Here's a pretty good explanation: 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 https://www.quora.com/How-do-metasearch-vertical-search-engi...
  - eriknstr 10y ago
    Thanks :)

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 ago
  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?
Stengo 10y ago
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.
- w0utert 10y ago
  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.

bsaul 10y ago

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.

_pmf_ 10y ago
So, you're proposing MVVM.
- JustSomeNobody 10y ago
  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.
  - achr2 10y ago
    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.
    - JustSomeNobody 10y ago
      I would argue there's a grey area between the 'view' and the 'controller', but not the 'model' and the 'view'. The model is logic and data and has absolutely nothing to do with presentation. But, I will concede there are 1001 ways to interpret these patterns (MV*).
      - achr2 10y ago
        Agreed - however, I wrote 'model' considering the binary separation that was suggested.

deleted 10y ago

[deleted]

HelloNurse 10y ago

s/Coordinator/Controller/g

currywurst 10y ago

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 10y ago

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.

afro88 10y ago

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.