4 ms·

Thanks, great comment! While outlining the post, I was uncertain what to call the particular group of classes (or concern) now called the Controllers. If you l

Thanks, great comment! While outlining the post, I was uncertain what to call the particular group of classes (or concern) now called the Controllers. If you look through the GitHub project, you'll find that at one point they were called Routers. I agree with you that this design is not a MVC by the traditional definition (i.e. Smalltalk's), however there are many variants out there, see for example Apple's https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html https://developer.apple.com/library/archive/documentation/Ge..., that I didn't think it would hurt 'to add' another. As long as it's clearly defined what it is. But perhaps it is not clear. In this design, the 'traditional controller' is already part of the front-end. One of the goals of this design is to keep the front-end only concerned with styling and the layout of the application, and not the logic or the flow. So from the front-end, the user-interactions will be forwarded down to the 'back-end' Controllers. Those controllers are responsible for the flow of the application. The back-end includes logic and models in the traditional sense, see for example the DocumentsModel (https://github.com/Fagrell/clean-editor/blob/master/lib/public/models/documents-model.h https://github.com/Fagrell/clean-editor/blob/master/lib/publ...), however there are also models that correspond to specific Components. Those "Model Components" contain logic and a state, e.g. the MenuModel referred to in the post. Perhaps an even better separation would be to add another layer? - UI front-end - View/Component layer -> includes the 'view and controller by the traditional definition'. - Router/Controller layer -> includes Models for specific components and Routers (as Controllers are defined in the post). Defines the flow. - Back-end layer -> includes models by the traditional definition. Thoughts?

dkersten 8y ago
The apple diagram doesn’t look too far off what quietbritishjim described though, assuming that the “updates” arrow from controller to model is the model asking for an update, but the model actually implementing the logic. Personally, I hate the name controller because its really unclear to me what they actually do. What do they control? The actual update logic is part of the domain knowledge, so that should live in the model itself, as quietbritishjim said. Router is a better name imho (even if itself not a perfect name).

dkersten 8y ago

The apple diagram doesn’t look too far off what quietbritishjim described though, assuming that the “updates” arrow from controller to model is the model asking for an update, but the model actually implementing the logic. Personally, I hate the name controller because its really unclear to me what they actually do. What do they control? The actual update logic is part of the domain knowledge, so that should live in the model itself, as quietbritishjim said. Router is a better name imho (even if itself not a perfect name).