Item — HN Reader

Yeah, M-V-C are all roles, not concrete objects. The C mediates between the input devices and the model, but in practice views can and often do fulfill that role as well. Cocoa views, for example, also fulfill the C role.

Different formulations of M-V-C have the C deal with more complex interactions, with sequences of interactive prompts like wizards.

The update is essentially automatic, and yes: MVC already solved the "problem with MVC" React/Redux/Elm/SwiftUI claim to solve. In 1979.

1 comments

I like my Controller to be responsible for all the "business logic" so that its all in one place. It's the important part. The View layer is always fairly verbose and full of fluff. Especially if you have a lot of animation and formatting type code.

> I like my Controller to be responsible for all the "business logic" so that its all in one place.

Business logic is supposed to go in the model. All of it. Because it's the important part.

Controller these days can be largely empty.

"MODELS Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.

There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand. The nodes of a model should therefore represent an identifiable part of the problem.

The nodes of a model should all be on the same problem level, it is confusing and considered bad form to mix problem-oriented nodes (e.g. calendar appointments) with implementation details (e.g. paragraphs)."

https://web.archive.org/web/20090424042645/http://heim.ifi.u...