3 ms·

MVC is understood to be the primary partition of an application's architecture. It does not obviate the need for further code organization, which is done in all

MVC is understood to be the primary partition of an application's architecture. It does not obviate the need for further code organization, which is done in all parts, Model, View and Controller. When the author says "controllers are nice self-contained bit of...[what I don't know?]", and they use that as the justification to throw away the paradigm in favor of another with Model-View-Operations+Events they show they don't understand this. Worse the proposed paradigm does not then collect all the controller code in one place, so the overall lifecycle of the application would be harder to piece together from Operations+Events modules without an overarching Controller to govern the two of them.

jkoudys 7y ago
Yeah - build out a graphql service on top of existing models, and you'll get a pretty clear picture about what the C ought to represent. You can find plenty of situations where the implementation of any of those letters is extremely thin: lots of services where the View is almost nothing (often just a JSON serialization of some of the models), or where the models are very thin. It boils down to a weirdly common, but deeply flawed, view that all the letters in your abstraction's initialism should be of equal complexity. With Views, it seems to be easy for devs to understand that there is significant differences in the underlying approaches: are you organizing your views into page templates, serializing for some special client to consume, building components that compose one another, etc. I don't know why we can't wrap our heads around Controllers also having different approaches.
gonational 7y ago
+1 so much. In my opinion, the mistake the OP makes is in not realizing that the dogmatic application of a design pattern is the fundamental issue to begin with. So then the solution offered is another design pattern that can be dogmatically followed. If we know that you need a UI (view), and we know that you need to represent your data in an expressive manner (model), and you need something to pull those things together for a user, a router and controller does not automatically come to mean “put all your logic here!” Instead, it means something more like “here’s where you can tie things together in whatever way makes the most sense for your application”, which lets you e.g., use AOP to handle auth (like Django decorators or middleware), delegation to a service like a REST API (e.g., Django REST Framework), or basic one-off views for simple tasks. If something like this MOVE was to become the next big thing, I think there’s a good chance we’ll be rewriting a lot of projects to use MVC in 10 years. Don’t blame bad code on a proven and very flexible design pattern that solves a very real problem. Blame bad code on bad coders.
- riazrizvi 7y ago
  Personally I see this design pattern simply as an application of Dijkstra’s Separation Of Concerns. That MVC is the best (most orthogonal and balanced) division of concerns in a gui based app.

jkoudys 7y ago

Yeah - build out a graphql service on top of existing models, and you'll get a pretty clear picture about what the C ought to represent. You can find plenty of situations where the implementation of any of those letters is extremely thin: lots of services where the View is almost nothing (often just a JSON serialization of some of the models), or where the models are very thin. It boils down to a weirdly common, but deeply flawed, view that all the letters in your abstraction's initialism should be of equal complexity. With Views, it seems to be easy for devs to understand that there is significant differences in the underlying approaches: are you organizing your views into page templates, serializing for some special client to consume, building components that compose one another, etc. I don't know why we can't wrap our heads around Controllers also having different approaches.

gonational 7y ago

+1 so much. In my opinion, the mistake the OP makes is in not realizing that the dogmatic application of a design pattern is the fundamental issue to begin with. So then the solution offered is another design pattern that can be dogmatically followed. If we know that you need a UI (view), and we know that you need to represent your data in an expressive manner (model), and you need something to pull those things together for a user, a router and controller does not automatically come to mean “put all your logic here!” Instead, it means something more like “here’s where you can tie things together in whatever way makes the most sense for your application”, which lets you e.g., use AOP to handle auth (like Django decorators or middleware), delegation to a service like a REST API (e.g., Django REST Framework), or basic one-off views for simple tasks. If something like this MOVE was to become the next big thing, I think there’s a good chance we’ll be rewriting a lot of projects to use MVC in 10 years. Don’t blame bad code on a proven and very flexible design pattern that solves a very real problem. Blame bad code on bad coders.

riazrizvi 7y ago
Personally I see this design pattern simply as an application of Dijkstra’s Separation Of Concerns. That MVC is the best (most orthogonal and balanced) division of concerns in a gui based app.