[barrkel]

Having used many different ORMs that let you think that your business models could just gain persistence with a little sprinking of automagic, I far prefer the non-object-orientation of ActiveRecord.

Databases aren't object-oriented. Thinking of them with an is-a, LSP etc. mindset is a recipe for pain down the road. Databases are containers for facts: a means of storing, finding, synthesizing and manipulating facts. Your User class isn't a user of your application; IMO it's wrong to think of it as an object, because it could just be a slice of the User's facts (e.g. a subset of the columns).

I'm not a big fan of object orientation any more, and I like my databases to be stores of facts. The data in the database is primary; code in the application is secondary. Persistence isn't something I add to my benighted objects to let them be reanimated by query; persistence is what lets me briefly get a handy representation of a tuple locally.

To my mind, ActiveRecord models are little more than hashes with a nicer syntax. I don't need them to be much more; I don't want them to be much more. You can try and add methods and make them smaller, but coordinating the manipulation of facts is problematic in a transactional world, and the responsibilities aren't clear either. Object orientation is predicated on the idea of message sends and hidden state; tables have explicit state and no behaviour. Not a good match.

[spacemanmatt]

Honestly, I feel like OO has been a net harm to the practice. It is a useful code reuse pattern but I feel like it has gotten far too much play.

[pm24601]

Especially true if there are more than 2 codebases interacting with the same database table.