4 ms·

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 relyin

by 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.
JustSomeNobody 10y ago
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 10y ago
  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.
  - Stengo 10y ago
    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.
  - JustSomeNobody 10y ago
    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 10y ago
      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.

by Stengo 10y ago

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.

JustSomeNobody 10y ago

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