One of the other markers of "true MVC" I look for is that you ought to have pervasive mixing and matching of the pieces. It is common for models to see some reuse in multiple "views" and "controllers", but if all or almost all of your controllers match up to precisely one view, then you're burning design budget on a distinction that is buying you nothing. If you've got strictly one-to-one-to-one matches for each model, view, and controller, then you're just setting your design budget on fire.

Another major aspect of the original "true" MVC is multiple simultaneous views on to the same model, e.g., a CAD program with two completely live views on the same object, instantly reflecting changes made in one view in the other. In this case MVC is less "good idea" than "table stakes".

I agree that MVC has fuzzed out into a useless term, but if the original is to be recovered and turned into something useful, the key is not to focus on the solution so much as the problem. Are you writing something like a CAD program with rich simultaneous editing? Then you probably have MVC whether you like it or realize it or not. The farther you get from that, the less you probably have it... and most supposed uses of it I see are pretty far from that.

▲

catlifeonmars 4 days ago | parent | next [-]

> if all or almost all of your controllers match up to precisely one view, then you're burning design budget on a distinction that is buying you nothing.

This is a really insightful way to frame it.

▲

RossBencina 4 days ago | parent | prev | next [-]

> if all or almost all of your controllers match up to precisely one view, then you're burning design budget on a distinction that is buying you nothing.

Could you give an example? I've never understood how one could possibly reuse a Controller independently of a View. At a minimum any kind of mouse-based direct manipulation requires the Controller having access to the displayed geometry in order to implement hit testing. E.g. how is a Controller supposed to update the selection range in a text editor without screen-coordinate character extent information from the view, or a drawing editor Controller accessing scene graph geometry for object selection, control handle manipulation, etc.

	▲	mpweiher 4 days ago \| parent \| next [-]
		> I've never understood how one could possibly reuse a Controller independently of a View. And you're absolutely right! The problem you're seeing is one of the misunderstandings/misinterpretations of MVC, that the controller is for all interactions/editing. It's not. It's perfectly fine for the View to handle this.
	▲	jerf 3 days ago \| parent \| prev [-]
		Honestly I think that was a stretch all along. It is conceivable that two views could present a similar enough interface that the same controller could drive them, e.g., an isometric and an orthographic view on to the same object might be able to be driven by the same controller, which, recall, is doing things like propagating changes between the two views, not just "driving" them directly, so if the view is controlling the coordinate mapping you might be able to use the same controller for both. In practice I suspect things end up 1-to-1 on the View and the Controller fairly often, although in an inheritance-based system there's probably some useful shared functionality in superclasses within a given system that could arguably fuzz whether or not it is "truly" 1-to-1. In practice most "MVC" in the wild in things like web frameworks where it is just completely inappropriate is actually "M and everything else"; there's a clear Model, and then a whole bunch of code that uses models and changes models but that is not usefully modeled by a "View" and "Controller" distinction. MVC is completely missing a client-server concept as well, and it really shows. And while I will absolutely say that that design is not only not "true" MVC but isn't meaningfully "MVC" at all, what it actually is is not so bad. "Models" have great utility in many places, indeed is arguably one of the fundamental tools of programming, but "VC" is something that can be applied to them in certain circumstances but don't otherwise have any particular special relationship to "Models" such that where ever a model goes some Views and Controllers must be tagging along. Models are everywhere, MVC is a useful concept in certain domains where the requirements drive in that direction super, super hard (and web frameworks are not one of them).

▲

kqr 4 days ago | parent | prev | next [-]

Oooh. Now I get it. I've been dismissive of MVC for nearly as long as I've known it but I realise I've only seen the bad versions. What you describe as correct sounds much more sensible.

▲

skydhash 4 days ago | parent | prev [-]

> If you've got strictly one-to-one-to-one matches for each model, view, and controller, then you're just setting your design budget on fire.

That's sensible. But it's generally useful to split your core state from your presentation, and then you'll find strands of logic that belongs to neither, generally glue code, but some can be useful enough to warrant a module of their own. Also your core state can be alien from the view itself (think a game data (invisible walls, sound objects) and the actual rendering).

Maybe this architecture is not MVC, but MVC can be a first stab for a quick and dirty separation. Then once a cleaner separation can be done by isolating specific modules (in layers, graph, whatever)

	▲	hurril 4 days ago \| parent [-]
		I think that a big problem here is the fact that in OOP, everything is an object, i.e.: a class. And if all you have is a hammer, then .... But it is much better to picture the model, controller and the view as emergent. But implementing this in OOP is too challenging because some things in either of those three domains are going to be a process, or a piece of state or a role, etc. And in implementing some process, what is it? As in: what is its encoding in $language and where does it go? So you end up with the local stamp collectors in the office and get into an argument of: it is part of the model, so should be in the Model class. "Process, nah, that is totally a controller aspect. It does something." etc.