The problem with controllers
karmajunkie.com
The problem with controllers
1–10 of 23 posts
Re: The problem with controllers
#2This is a good read, and something I agree with. The command pattern that you're showing here almost feels like the "write" inverse to the Presenter "read" action.
The way I've been thinking about it for myself is to imagine your Domain Objects as this 3D space of object relationships and interactions. So a Presenter cuts a 2D plane through that space and let's you view from a certain perspective.
In the case of Commands, you're taking a certain perspective and mutating that 3D space through it.
Not sure if that helps anyone else :-)
Also the focused_controller project looks really interesting as well. I was working on my own web framework, that made Actions first class objects as well. And since it was built on this slick IoC library, your Actions could just declare they need this Command, or these two Services to complete the request and they would automagically get them. I really like the idea of "one object(graph) to represent accomplishing a task", and then just having that object(graph) go do the work.
Re: The problem with controllers
#3The issue of model code creeping into controllers is common with rails and rails-style frameworks precisely because they are not MVC frameworks. MVC was a pattern created for making GUI apps in smalltalk in the 70s/80s. It has gradually been warped and twisted since then, especially when people tried to cludge it onto web development. The resulting thing doesn't really resemble MVC at all, and certainly doesn't deliver the benefits MVC was created to deliver.
MVC is a triangle, rails style frameworks are a line. This is called MVA (Model-View-Adapter). The "adapter" being in between the view and the model who can only interact with the adapter and not each other. The second issue is that in adapting MVC to the web, many frameworks continued with the "one controller per view" notion, despite that being done because of the limitations imposed when creating GUI apps. There is no need for multiple controllers in a web app, all input comes in the same way no matter what view the user is seeing. In fact, the user doesn't even need to be seeing a view, there is nothing tying a view to what actions are possible, you can always submit any http request you want. Your "routes" are your controller, there is no need for a second level of controllers on top of that.
The goal of MVC was to expose model functionality to the user directly so they could understand and work with the domain model clearly and easily. Controller meant "controls the input and output" not "controls the users experience". The guy who created MVC considers naked objects style frameworks to be the closest thing to MVC for the web, not rails style MVA frameworks.
And there is something very weird about this statement:
>On top of that, it’s very common to see logic pushed down into the model
Of course that is common, that is what is supposed to happen. Models are not "stupid containers to pretend to kinda represent my DB sorta but not really". Models are the business logic. Models are the actual application. You are modelling the domain, not modelling the database. The model is the domain, it is all the business logic. The view is the way we present information to the user. The controller is the part that handles input and output. Very simple and effective system, but very poorly understood and virtually never used any more.
Re: The problem with controllers
#4The issue of model code creeping into controllers is common with rails and rails-style frameworks precisely because they are not MVC frameworks. MVC was a pattern created for making GUI apps in smalltalk in the 70s/80s. It has gradually been warped and twisted since then, especially when people tried to cludge it onto web development. The resulting thing doesn't really resemble MVC at all, and certainly doesn't deliv…
The problem with "logic getting pushed down into the model" and the gist of the statement is that not all logic is domain logic. Reaching out and touching facebook for a status update, for example, is not domain logic and doesn't belong in a model. And while I agree that we should be modeling the domain, not the database, I think its clear from working on a lot of complex and legacy applications over the last several years rails developers model what the database allows, not the actual domain, thanks to the widespread acceptance of ActiveRecord as the only tool in that toolchest.
I'm in 100% agreement WRT to MVC—Rails' idea of MVC was never really MVC as MVC was originally envisioned.
Re: The problem with controllers
#5The issue of model code creeping into controllers is common with rails and rails-style frameworks precisely because they are not MVC frameworks. MVC was a pattern created for making GUI apps in smalltalk in the 70s/80s. It has gradually been warped and twisted since then, especially when people tried to cludge it onto web development. The resulting thing doesn't really resemble MVC at all, and certainly doesn't deliv…
The problem with "logic getting pushed down into the model" and the gist of the statement is that not all logic is domain logic. Reaching out and touching facebook for a status update, for example, is not domain logic and doesn't belong in a model. And while I agree that we should be modeling the domain, not the database, I think its clear from working on a lot of complex and legacy applications over the last several…
I don't understand the distinction of "not domain logic". If your application requirements are "when user does X, update facebook" then that is clearly part of the domain and should absolutely be in the models.
Re: The problem with controllers
#6The issue of model code creeping into controllers is common with rails and rails-style frameworks precisely because they are not MVC frameworks. MVC was a pattern created for making GUI apps in smalltalk in the 70s/80s. It has gradually been warped and twisted since then, especially when people tried to cludge it onto web development. The resulting thing doesn't really resemble MVC at all, and certainly doesn't deliv…
The problem with "logic getting pushed down into the model" and the gist of the statement is that not all logic is domain logic. Reaching out and touching facebook for a status update, for example, is not domain logic and doesn't belong in a model. And while I agree that we should be modeling the domain, not the database, I think its clear from working on a lot of complex and legacy applications over the last several…
> Rails' idea of MVC was never really MVC as MVC was originally envisioned.
It's worth noting that as originally envisioned, the controller directly dealt with the keyboard and mouse. I would argue that not only is Rails not MVC as originally envisioned, something that reanimated the original controller would probably suck.
MVC as done in Cocoa on the other hand, is really good. Stock, reusable controllers that simply mediate communication between models and views. If any MVC-style web framework had something like this, it would be pretty amazing.
Re: The problem with controllers
#7Kinda funny, I settled in on a "command" architecture for PHP apps around 2001 because the ORM kind of model always has some big semantic gap in it.
Re: The problem with controllers
#8Slightly off-topic, but does anyone have any resources for learning more about these and other design patterns that show up on HN from time to time?
Re: The problem with controllers
#9Earlier quoted context omitted.
The problem with "logic getting pushed down into the model" and the gist of the statement is that not all logic is domain logic. Reaching out and touching facebook for a status update, for example, is not domain logic and doesn't belong in a model. And while I agree that we should be modeling the domain, not the database, I think its clear from working on a lot of complex and legacy applications over the last several…
I don't understand the distinction of "not domain logic". If your application requirements are "when user does X, update facebook" then that is clearly part of the domain and should absolutely be in the models.
Oh, i disagree with that completely. A user having a status is domain logic. Pulling that status from an external dependency is decidedly not.
Re: The problem with controllers
#10Slightly off-topic, but does anyone have any resources for learning more about these and other design patterns that show up on HN from time to time?
Design Patterns in Ruby would probably be a good place to start, then the original GoF Design Patterns book, along with Enterprise Design Patterns which came later.
Also check out the DDD/CQRS google group: http://groups.google.com/group/dddcqrs