I just finished reading this post from m.onkey.org on how to put your session into your models. First off, I love this guy, and his site, and most of what he says, but I’ve had it up to here with this nonsense. I also kind of felt a little dissed by the PHP comment. I understand he was joking, and it was kind of funny, PHP programmers are NOTORIOUS for using $_SESSION to store EVERYTHING. At the same time, as Voorhaus says, all comedy is truth and pain, and the truth is that PHP programmers do that, and the pain is that many programmers coming to Ruby and Rails feel alienated by that community because they are so opinionated (And not always right). Rails is kind of Opinionated by design, and that’s okay, but more often than not, the Rails and Ruby community is uneccessarily sadistic in its treatment of contradictory opinions, they have a “my way or the highway” kind of speech when in fact, you can do it anyway you want, and all they are doing is looking like douche bags for treating you as a sub-human for having a contradictory opinion. As I see it, at the core of the above issue, sessions in the model, is global variables, and the irrational fear of them.
There is some practicality in not depending on global variables, especially when you are TALKING about programming. When you are doing it, it’s another story. They can theoretically be the source of problems. Yes I understand that Global variables can be seen as a system design flaw and are an incorrect implementation of MVC separation and a violation of Dependency Injection (Kind of). Why? Because your domain logic shouldn’t depend on the state of other aspects of the system to work. All external data and instances needed by a particular class/object should be provided (Injected) into the model from the outside.
All relevant information needed by the Model is SUPPOSED to be provided to it during a method call FROM the Controller. Pretty much full stop. You aren’t supposed to instantiate classes inside a Model method, class instances should be given to the Model from the Controller.
This is because Objects in OOP are more than just Glorified Namespaces, which admittedly is how most novice programmers use them. They seem to be just a clever way to collect up functions and variables. That’s a very limited, albeit functional, view of Objects in OOP.
Objects SHOULD always be decoupled completely from any kind of dependency of the actual System Architecture, what that means is the Implementation of domain logic in a Model, SHOULD not depend on, or be coupled to, the Implementation of the System as a whole, OR the architecture of ANY other part of the system, such as a Controller, or even a View.