5 ms·

Mostly disagree. Pure functions are beautiful and have their place, but not every function should be a pure function. And a Rails controller method is the oppos

by mdemare 14y ago

Mostly disagree. Pure functions are beautiful and have their place, but not every function should be a pure function. And a Rails controller method is the opposite of a pure function - it has a database connection, several file descriptors and hundreds of objects at its fingertips. That is its strength, and DI has no place there. That said, if you have a pure function, and you need to know the current time, consider keeping it pure with DI.

Rygu 14y ago
Sounds like the controllers described need some major refactoring. How many hundreds of lines are their unit tests? http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Single_responsibility_principle
mercurial 14y ago
Er. Obviously, not every function can be a pure function, otherwise your program will not work. However: - controllers should not touch the data layer directly (and therefore follow SRP) - controllers should have their business layer services injected from somewhere else This does not make them pure in the sense they remain (indirectly) functions with side-effects, by virtue on relying on business services, which themselves interact with data access services which do IO. However, it does make them testable without resorting to hacks and offers a clean interface.
- mdemare 14y ago
  The vast majority of Rails apps fail those conditions. I'd say that it's not the Rails Way to follow those precepts, so I believe your comment dismisses Rails in one stroke. I'm not sure if that's a very productive line of thought.
  - mercurial 14y ago
    It's not impossible to achieve with Rails, it depends on what you put in your fat models. There is nothing which keeps you from having an intermediate business layer. I'm not sure how you would handle DI cleanly though, maybe it's possible with Rails 3? My brief experiments with Rails date from a few years ago, so I'm a bit fuzzy about this sort of details. I'm confused about your comment regarding productivity. Either my recommendations are mostly valid, in the sense that they offer a distinct advantage over the current, Rails-y way of doing things, or they are not (but in which case you would need to make a cogent argument for why they are not). If they are, surely recognizing the shortcomings of a particular design/set of accepted practices is a benefit. The fact that Rails 3 has undergone significant architectural changes with the merge of Merb shows that Rails did not emerge perfect from the thigh of DHH. And we all strive to improve ourselves and the tools we work with (or alternatively, for those of us for whom this is not an option, we stay with PHP or VB and stare blindly at people talking about "MVC").

by mdemare 14y ago

Rygu 14y ago

Sounds like the controllers described need some major refactoring. How many hundreds of lines are their unit tests? http://en.wikipedia.org/wiki/Single_responsibility_principle http://en.wikipedia.org/wiki/Single_responsibility_principle

mercurial 14y ago

Er. Obviously, not every function can be a pure function, otherwise your program will not work. However: - controllers should not touch the data layer directly (and therefore follow SRP) - controllers should have their business layer services injected from somewhere else This does not make them pure in the sense they remain (indirectly) functions with side-effects, by virtue on relying on business services, which themselves interact with data access services which do IO. However, it does make them testable without resorting to hacks and offers a clean interface.

mdemare 14y ago
The vast majority of Rails apps fail those conditions. I'd say that it's not the Rails Way to follow those precepts, so I believe your comment dismisses Rails in one stroke. I'm not sure if that's a very productive line of thought.
- mercurial 14y ago
  It's not impossible to achieve with Rails, it depends on what you put in your fat models. There is nothing which keeps you from having an intermediate business layer. I'm not sure how you would handle DI cleanly though, maybe it's possible with Rails 3? My brief experiments with Rails date from a few years ago, so I'm a bit fuzzy about this sort of details. I'm confused about your comment regarding productivity. Either my recommendations are mostly valid, in the sense that they offer a distinct advantage over the current, Rails-y way of doing things, or they are not (but in which case you would need to make a cogent argument for why they are not). If they are, surely recognizing the shortcomings of a particular design/set of accepted practices is a benefit. The fact that Rails 3 has undergone significant architectural changes with the merge of Merb shows that Rails did not emerge perfect from the thigh of DHH. And we all strive to improve ourselves and the tools we work with (or alternatively, for those of us for whom this is not an option, we stay with PHP or VB and stare blindly at people talking about "MVC").