5 ms·

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility

It is interesting that iOS apps suffer the same sort of runaway complexity that often plagues Rails apps, whereby the controller absorbs too much responsibility and becomes unmanageable. This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. This points to a lack of developer education surrounding architecture and design. Most projects have too few abstractions, and/or a weak domain model. The Internet likes to complain about Java-style over-abstraction, but I've never seen that. I think devs don't like to think about architecture because it implies they're not doing things well, it is highly subjective, and they don't see the benefits immediately. All of these are poor reasons.

mpweiher 12y ago
The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller. Hmm...
- 21echoes 12y ago
  and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.
  - dep_b 12y ago
    There's no silver bullet method. If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see. If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all. I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right. We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.
  - UK-AL 12y ago
    Traditionally(on desktop applications) the model was injected into the view, then actions(save, delete, buttons etc) were performed on the controller. However the way Apples IBOutlet system works, makes this difficult. You link up the UI to fields on the controller. The first significantly reduces code size.
- dep_b 12y ago
  I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding. I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in some cases it's better to just let the View not only read the Model and represent it but also let it change values in the Model or even create a new one. But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View. I also like to argue that there could be something between the Controller and the View that handles specific chores like input validation and creation of objects from input fields. You have the opportunity to add Objects to your Storyboards for just that reason.
  - thoughtpalette 12y ago
    "But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View." Definitely agree
  - mpweiher 12y ago
    Hmm..you are talking letting the view "change the values in the Model". I thought "the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller" made it clear that I was talking about updating the view from the model, not vice versa. In MVC, the controller initiates changes in the model, not the view. However, the view updates itself from the model. Whether that's good or bad is a different story, but that's how MVC is defined.
- ktran03 12y ago
  You are thinking of the traditional conception of MVC, where the model notifies the views of updates and changes (i.e. they can talk to each other) Cocoa does not use the traditional notion of MVC. All documented here very clearly MVC as a Compound Design Pattern: https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html https://developer.apple.com/library/ios/documentation/genera... "The controller object in this compound design pattern incorporates the Mediator pattern as well as the Strategy pattern; it mediates the flow of data between model and view objects in both directions. Changes in model state are communicated to view objects through the controller objects of an application."
  - mariodiana 12y ago
    There's something else to architecting a Cocoa app that I want to add, mainly because I had heard this a while ago but only just recently figured out how to incorporate it. There are Cocoa programmers (my understanding is that it is mainly the O.G.'s) that make good use of class extensions and categories to split the functionality of a class into different source files. For example, if you have a view controller handling a table view that makes use of many delegate and datasource methods, it's easy to have code spilling all over the place. But you can use extensions and categories to separate out the delegate functionality into its own set of files, and do the same for the datasource as well. If you share the header files among the files, then to the computer it all works like one big class. But to the programmer -- and this is the whole point -- the functionality is broken out into conceptual units. What you end up with is still a "god class," but instead of being monolithic, you wind up with a god of many faces. (I'm whimsically calling it the "Brahma" pattern.) Anyway, I suggest people give it a try if they've been having trouble organizing their code. Does anyone on here have experience organizing their Cocoa apps this way? I'd be interested in hearing your input, since I've just gotten around to looking into this myself.
    - mattgreenrocks 12y ago
      If you want it to look prettier on-screen you can just an editor with code folding and hide all the irrelevant functions. Really, this is just a weird halfway house reminiscent of Rails' ActiveSupport::Concern. Much like that implementation, it encourages developers to address SRP by chopping the class up and calling it done. Difficulties in testing and reasoning are still in place, and the class is likely still too coupled. If the local units are truly independent concepts, then they should be split out into their own objects. Either make smaller objects that either model the domain closer, or abstract away needless technical details. For example, any sort of serialization (web service/DB) should be hidden behind a high-level class that obscures how it's done if only to firewall the dependency itself from leaking it's conceptual garbage over the rest of your code. This can be applied gradually with good effect. It's not an all-or-nothing proposition.
coldtea 12y ago
>This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. Well, you're supposed to have a different controller for every major view. And said controller can always delegate to some object model specific to your app.
matwood 12y ago
I completely agree. Years ago when starting an iOS app I suggested a few abstractions to the other devs and got the response that 'this is not an enterprise application.' The problem is that a complex iOS application can quickly become a lot of code. It is compounded by the fact that a lot of that code ends up in the view controllers.

mpweiher 12y ago

The problem, as with rails, is that the frameworks, documentation etc. encourage this. That's how you make the cool "look ma, no code" demos work: thin model ("ideally" just a CoreData object drawn in the modeler), UI painted in IB, controller to hook it all together. But it's less than ideal, er, for non-trivial programs. In fact, I've just recently had a junior dev. tell me that in MVC, the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller. Hmm...

21echoes 12y ago
and you'll also notice that the linked article says the same thing (that the model and view never touch each other but instead communicate through the controller)... I've always learned MVC as strict separation of model and view, but I've recently heard more and more people saying that they think they should talk.
- dep_b 12y ago
  There's no silver bullet method. If you do MVVM on an app that is sparse on input controls or text labels it's overkill. MVVM shines where you have a lot of data going back and forth in screens combined from different models and you want to be able to test everything you see. If you are doing an app that is much more graphical in nature and the models that feed it are not really mapping to databases or web services they gel much more natural with your UI and mixing them up with each other is no problem at all. I enjoyed MVVM a lot in WPF especially because of the two-way binding it provided. That was in an application that managed health care records so it was very text heavy and a lot of screens were taking context from Models left and right. We went with full MVVM for complex screens and direct Model mapping when we had a screen where you would edit just a support table, like a list of doctors or treatment types.
- UK-AL 12y ago
  Traditionally(on desktop applications) the model was injected into the view, then actions(save, delete, buttons etc) were performed on the controller. However the way Apples IBOutlet system works, makes this difficult. You link up the UI to fields on the controller. The first significantly reduces code size.
dep_b 12y ago
I think your junior dev shows some promise. Maybe too orthodox in his thinking or taking wrong conclusions from the right info, but at least a hopeful glimmer of understanding. I think the upper limit of possibilities a View should have interacting with a Model for me is the point where your View and Model map 1:1 and the user is able to update the fields of the Model represented in your View. You might argue that in some cases it's better to just let the View not only read the Model and represent it but also let it change values in the Model or even create a new one. But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View. I also like to argue that there could be something between the Controller and the View that handles specific chores like input validation and creation of objects from input fields. You have the opportunity to add Objects to your Storyboards for just that reason.
- thoughtpalette 12y ago
  "But the decision to read / save / delete the Model should always be taken by the Controller and never be done directly by the View." Definitely agree
- mpweiher 12y ago
  Hmm..you are talking letting the view "change the values in the Model". I thought "the view was not allowed to talk to the model, instead it had to be fed pre-digested info by the controller" made it clear that I was talking about updating the view from the model, not vice versa. In MVC, the controller initiates changes in the model, not the view. However, the view updates itself from the model. Whether that's good or bad is a different story, but that's how MVC is defined.
ktran03 12y ago
You are thinking of the traditional conception of MVC, where the model notifies the views of updates and changes (i.e. they can talk to each other) Cocoa does not use the traditional notion of MVC. All documented here very clearly MVC as a Compound Design Pattern: https://developer.apple.com/library/ios/documentation/general/conceptual/CocoaEncyclopedia/Model-View-Controller/Model-View-Controller.html https://developer.apple.com/library/ios/documentation/genera... "The controller object in this compound design pattern incorporates the Mediator pattern as well as the Strategy pattern; it mediates the flow of data between model and view objects in both directions. Changes in model state are communicated to view objects through the controller objects of an application."
- mariodiana 12y ago
  There's something else to architecting a Cocoa app that I want to add, mainly because I had heard this a while ago but only just recently figured out how to incorporate it. There are Cocoa programmers (my understanding is that it is mainly the O.G.'s) that make good use of class extensions and categories to split the functionality of a class into different source files. For example, if you have a view controller handling a table view that makes use of many delegate and datasource methods, it's easy to have code spilling all over the place. But you can use extensions and categories to separate out the delegate functionality into its own set of files, and do the same for the datasource as well. If you share the header files among the files, then to the computer it all works like one big class. But to the programmer -- and this is the whole point -- the functionality is broken out into conceptual units. What you end up with is still a "god class," but instead of being monolithic, you wind up with a god of many faces. (I'm whimsically calling it the "Brahma" pattern.) Anyway, I suggest people give it a try if they've been having trouble organizing their code. Does anyone on here have experience organizing their Cocoa apps this way? I'd be interested in hearing your input, since I've just gotten around to looking into this myself.
  - mattgreenrocks 12y ago
    If you want it to look prettier on-screen you can just an editor with code folding and hide all the irrelevant functions. Really, this is just a weird halfway house reminiscent of Rails' ActiveSupport::Concern. Much like that implementation, it encourages developers to address SRP by chopping the class up and calling it done. Difficulties in testing and reasoning are still in place, and the class is likely still too coupled. If the local units are truly independent concepts, then they should be split out into their own objects. Either make smaller objects that either model the domain closer, or abstract away needless technical details. For example, any sort of serialization (web service/DB) should be hidden behind a high-level class that obscures how it's done if only to firewall the dependency itself from leaking it's conceptual garbage over the rest of your code. This can be applied gradually with good effect. It's not an all-or-nothing proposition.

coldtea 12y ago

>This is usually the collateral damage of an app growing within the overly tight conceptual confines of model/controller. Well, you're supposed to have a different controller for every major view. And said controller can always delegate to some object model specific to your app.

matwood 12y ago

I completely agree. Years ago when starting an iOS app I suggested a few abstractions to the other devs and got the response that 'this is not an enterprise application.' The problem is that a complex iOS application can quickly become a lot of code. It is compounded by the fact that a lot of that code ends up in the view controllers.