4 ms·
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 i
by 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 agoIt'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").