Very different comparison to the patterns Fowler presented. The patterns GoF presented were very basic, and were interesting then with languages like C++ when people were still fucking up many of the basic patterns. The number of horribly broken C++ Singleton implementations I've seen, for example, beggars belief. Today that's less of an issue.
The patterns Fowler presents are, as the title says, about architecture not low level implementation, and they are patterns you will tend to find in pretty much any large software project today yet that people still manage to fuck up royally, which is the reason the patterns matter.
Patters are nothing but recipes of best practice. They're not meant to be "intriguing" once you understand the tradeoffs. They're meant to become boring and bland and trivial once people are comfortable with them and their implementation is well understood. They're also meant to give people a shared vocabulary for talking about it. That's the entire point.
Most of the patterns in EAR are nowhere that for most people, judging by the code I see regularly and judging by how there's still this cargo cult around the AR pattern by people who in many cases have not even heard about the other ORM patterns presented by Fowler, much less other alternatives.
> There is limited time and large number of books - one has to be picky.
If I were to pick any book on software development from the last 10-15 years I'd like everyone to read, it'd be Enterprise Software Architecture, for a simple reason: I still see people using those patterns every day, yet screwing them up in horrible ways. Maybe you don't need it, but the developers I come across for the most part sure do.
> 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.
That is only true if you're dealing with a query that simple (even then, the "Rails way" of doing your example would be Person.find_by_lastname(lastname)). On the other hand, I've read the code of dozens of Rails apps that contains several lines long SQL queries littered just because they could.
The biggest problem in your example as why you are asking for persons with specific last names in the first place. 9/10 when I see code like that, it is the wrong (too low level) question, and leaks domain logic that should be confined to the model.
Also, what happens when you need to serve that query from a web API instead of your database? From a full text engine? From file? From a noSQL database? From on disk hash table? I've had to do all of these - often several from the same application. With a suitable architecture you just plug in your new storage and implement the finders you need supported, and won't have to play "hunt the raw SQL". Changing column names is the least of my concerns - that can be fixed with a simple search replace.
You also miss the point when you say you can do a base model class and do a mapper yourself: The point is the architecture of AR makes leaking SQL which often ends up in controllers and other places they don't belong all over the place the easy default, while implementing cleaner abstractions is more work.
The end result is that most places where AR is used end up with high degrees of coupling for no good reason.
If everyone used AR in a disciplined way and avoided littering their controllers and other code with query details that belongs in their models, there wouldn't be a problem.
Your argument reminds me of the old memory-protection vs. no memory-protection in the 80's, where the Amiga camp for example tended to be bitterly against memory protection because it was seen as expensive, slow and enabling lazy developers. Expecting developers to write clean code with ActiveRecord is a bit similar to expecting developers to write code free of bad memory accesses without memory protection - it makes it far too easy to do the wrong thing.
> github, twitter, heroku et al would like to disagree.
And Ebay at least used to be written using ISAPI modules, and large parts of Yahoo runs or used to run on a horrific mess of PHP and Perl (I used to work at Yahoo; there was a lot of dreadful code). Your point again?
(and Twitter is a particularly bad example given how much time they spend moaning about how they've needed to move most stuff off Ruby)
Besides, pointing to web startups as the pinnacle of engineering quality is ridiculous at best of times - while some of what happens in web startups is amazing, there are also plenty of areas where we're still lagging 20 years behind engineering practices in the enterprise space. Active Record was not by any means a new pattern, for example - none of the patterns in EAR were. They were Fowler's cataloguing of well established patterns with years of use in industry.
Rails, and AR, is still better than a lot of the alternatives. That does not mean there are not better ways for a lot of uses than resorting to AR.
> Person.where("last_name = ?", last_name) makes it unsuitable for large projects?
Strawman. If you think simple cases like that is what it is about, you've not seen much complicated Rails code, and it's a waste having this discussion with you.
> It has been long enough to call it time tested.
So is BASIC. That doesn't mean it's good. "Time tested" is not in itself an argument for anything.
> 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 don't use AR the library unless I absolutely have to, which means I only use it if I help out on Rails projects where I can't dictate policy. Otherwise I'll generally use Sequel, which though it suffers from many similar flaws drawn in large part to inspiration from AR, is cleaner in many ways. There's many things I'd love to change about it, but I already have at twice as much stuff to do as I should.
For small projects I might use the Sequel schema module which implements the AR pattern, and which allows for a lot of the same crap that people do with AR the library, but still makes it a lot easier to avoid raw SQL. The AR pattern has its place.
But for larger projects I'd generally be inclined to implement mappers, then often with Sequel (without the schema/model module) used internally by the mappers only.
