Now that is over and my latest delivery of is done, I've just realized a better articulation of *why* I believe UIViewController belongs in the View layer of your app

It's basically the idea that, to me (and you're welcome to disagree cuz you know we're all human), a UIView is a *static* thing. You give it text/colors/images to show, and that's it.

To me, *mutating* that, whether immediately or w/ animation, does not belong in a "static" UIView, but belongs to that view's UIViewController.

Thus, UIViewController is responsible for shoving data into your UI and shoving *around* your UI, and not much else. To me, that makes it a View.

@davedelong In my former office this approach led to gigantic UIViewController classes. We used to make jokes about, how MVC stands for "Massive View Controller"... This became one of the main reasons for us to switch to MVVM instead since the "weight" was more evenly distributed.

Since you are a veteran, I am _really_ curious about your opinion on this topic.

@geekygent boy have I got a conference talk for you... 😉

Basically, I avoid Massive View Controller through a lot of application of child view controllers and small, single-purpose view controllers. All business logic gets moved out of them to higher levels

Check out any of the "A Better MVC" videos linked to here:

(The one will be up in the next few days)

@davedelong Awesome! Will do! Thank you for the quick response! Have safe travels back!

@geekygent Alternatively if you prefer reading, I've got a series of blog posts on the idea (although my ideas have evolved over time, which I try to capture).

Starting here:

@davedelong effectively UIViewController is the reference type and you are advocating UIView as a structure? That doesn’t seem to be the case and I am not sure that is easily doable.

@phausler I’m gonna have to think about that. My gut reaction is “no”, but there might be some truth to it. UIView is static in the sense that it doesn’t change itself; changes generally need to be externally applied

@davedelong So tl;dr: you're saying there should simply be Model / View, View = View+ViewController?

@pixel no, you still need controllers.

It’s just that those controllers are UIViewControllers

@davedelong OOH, so never have "UILabelControllers", etc. There should be something more like a many views -> 1 controller representation? i.e. a ViewController is one "Screen" not one "view"? This is basically how the majority of my apps work 😊

@pixel in my apps, a screen is composed of many view controllers

@pixel feel free to ask more questions and/or check out the videos on the CV page of my site. Gotta hit the sack now. It’s 3am here

@davedelong Will do! I was actually having almost this exact discussion with one of my directs yesterday :)

@davedelong I’ve been playing around with a combination of this approach and MVVM and one screen is built of many view controllers, each with a view model protocol. Under the hood they share a common view model that implements many protocols to transform data, but the view controllers don’t need to know that (and it makes testing straightforward).

@davedelong I think it’s important to make clear what the level of “data” is. For example, I believe the unit of data that should be shoved into a View is the Model object (or View Model for those so inclined). A View Controller should avoid code like “view.nameLabel.text =”.

If you agree at that level, I still need to think about whether I agree with the static/animations part. I think cell animations generally belong in the cell.

@davedelong I totally agree with this reasoning. But one question: how much logic should a custom control handle? I’ve had this back and forth with myself for many months while writing my editor app, and I’ve come to the conclusion that parsing user interactions should be 100% the control’s responsibility. But this has made my editor-related view controllers mostly shims and boilerplate between the editor and the document model + preferences storage, and I question how wise that is.

@brunoph A bit hard to explain in a short-form format, but basically: each layer of the app is responsible for interpreting its input and and translating it to a semantically appropriate abstraction that it can output.

In general, it sounds like a control is a good place to handle interaction. However, that's not necessarily *always* true; just probably generally true.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!