| > I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR. Then I suggestion you read Enterprise Application Architecture. It's a great book for the way it formalises a number of very common patterns in a very concise way. It is also directly or indirectly the inspiration for a large number of recent ORM's and worth reading for that reason alone. Active Record the ORM is a direct implementation of Active Record the pattern as described in EAR for example. Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern. > Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views? Because the ORM spews methods all over the models that expose schema details whether or not they are relevant to the domain model. > Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted? No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Yet it is hard enough to work with AR without resorting to crap like this, that you see stuff like that all over most code that uses AR. At least all the code I've looked at. > More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem. The problem is not what AR does, it is how it does it, and the way it's been packaged with Rails and given legitimacy that way despite being an exceedingly poor solution for anything but tiny projects because of a) the choice of the Active Record pattern, b) the poor level of abstraction. A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives. |
I have a general dislike for Fowler church of patterns. That is not to say I haven't gone through what is listed on his site. I didn't find it intriguing enough. I derive 100 times more value reading K&R than GoF. There is limited time and large number of books - one has to be picky.
> No, I am suggesting that, e.g. Person.where("some random SQL") is horrible.
Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill. If you are so insistent, it isn't really hard to do a base model class which inherits from ActiveRecord::Base and do the mapper yourself.
> exceedingly poor solution for anything but tiny projects
github, twitter, heroku et al would like to disagree. Person.where("last_name = ?", last_name) makes it unsuitable for large projects? Personally, I have seen 1% cases where a migration changes column names, and when it does, re-factoring the code base for column name changes will take less than 2 minutes.
> A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.
I don't understand. You are quoting it as if AR is the new kid on the block. It has been long enough to call it time tested. If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives. I am not a fan of InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter and I would stick with Person.where("last_name = ?", last_name) and will fork AR if someone has a bright idea of adding layers of abstractions over a simple query.