Well anything is better than the old and original Mysql extension for PHP. If you Google "PHP MySQL tutorial", there's lots of tutorials teaching still about mysql_connect and mysql_query.

AR is controversial but it is approachable.

In addition, I figure, those old PHP tutorials (code like it's the 2003!) are giving bad example and beginners can't understand the difference or realize that mysql_query + bunch of procedural code per file * 10 can be bad thing.

I should've been a bit more clearer. Laravel taught him bunch of generic best practices (like deployment procedures, GIT, OOP, MVC, etc) and using Laravel Query Builder and/or Eloquent makes the DB code more sane compared to mysql_query.

Laravel isn't the only framework which could've done this but like AR, it's quite beginner friendly :)

I spent a good while trying to integrate Doctrine into my projects, and in the end I found it bloated and overly verbose and went back to PDO.

I am sure that it has valid use cases, but for a lot of straightforward PHP projects, it's complete overkill and adds more work than it saves (in my opinion of course).

I agree with knowing PDO though, I would say that's required knowledge for any self-respecting PHP developer.

> I spent a good while trying to integrate Doctrine into my projects, and in the end I found it bloated and overly verbose and went back to PDO.

Were you integrating Doctrine, or were you integrating Doctrine/DBAL, as the parent poster recommends?

Doctrine/DBAL is a bunch of useful helpers around PDO which take out a lot of the repetitive coding (and let me delete many home-grown methods I'd created to 'help' PDO)

Doctrine is great for keeping rails on developers of various skill levels in large projects. But it does come at a cost of overhead.

Most of the time for simple crud operations it doesn't matter, as long as you handle proxy generation and caching correctly. It can add up when you try to write code working on datasets.

In those cases, I bypass doctrine and go direct to SQL.

> Active Record Pattern is somehow controversial.

What is controversial about AR?

> What is controversial about AR?

How it represents rows as objects. How it makes people think about them.

How it conflates modelling the domain with database structure.

https://www.google.co.uk/search?q=activerecord+vs+datamapper

> How it represents rows as objects.

A row is the DBMS's model of an entity in the domain. An object is an object-oriented programming language's model of an entity in the domain.

Representing domain entities as objects in the PL that are backed by rows in a database relation (view or table), which is what the Active Record pattern does, is reasonable.

> How it conflates modelling the domain with database structure.

Modelling the domain should drive both application and database structure; the Active Record pattern doesn't promote anything bad I can see there.

There are particular choices in database design that are encouraged by the path of least resistance in some Active Record implementations and related tooling that are, perhaps, not so great.

> A row is the DBMS's model of an entity in the domain. An object is an object-oriented programming language's model of an entity in the domain.

There's why we disagree. I believe the DBMS's model shouldn't be conflated with the application's model. Sometimes the row is an entity in the domain; however consider a normalised data structure, where the entity as the application understands it may span a couple of tables. Or involve data from another source.

My understanding is ORMs were originally developed to handle the mapping between domains, and https://en.wikipedia.org/wiki/Object-relational_impedance_mi....

DataMappers also shine when working against a legacy database or one that cannot be changed. But ActiveRecord is a heck of a lot simpler to work with.

> Modelling the domain should drive both application and database structure

I am luke-warm on this coupling; too often it leads to the application structured around the database representation, as you point out. Sometimes this is sensible (e.g. a data-processing system), but in my experience it comes back to bite later on.

I'm interested to hear your experience - do your application models match the database structure?

> I believe the DBMS's model shouldn't be conflated with the application's model. Sometimes the row is an entity in the domain; however consider a normalised data structure, where the entity as the application understands it may span a couple of tables.

If the right DB structure spans a couple of tables, then it probably shouldn't be one monolithic object in an application model (there might be a "central" object of sorts, with other related objects of which it is composed; that doesn't mean the models are identical, or even exactly 1:1, as, e.g., aggregates are sensibly single objects in an OO design, but multiple rows with some common attribute in a relational design for the same domain model, but Active Record generally accommodates that.)

> DataMappers also shine when working against a legacy database or one that cannot be changed.

I generally prefer Data Mapper as a pattern for a variety of reasons (just not the particular ones that were raised as problems with AR upthread, or, at least, for reasons that seem different to me than how those were phrased) -- even though I find that there is a usually a close correspondence between the natural relational model for a domain and the natural OO model, with divergences in models usually indicating a violation of good design principles on one side or the other (often the SRP on the OO side), I find AR itself is a violation of the SRP principle; the description of the pattern in PofEAA should raise a big red warning flag about this: "Each Active Record is responsible for saving and loading to the database and also for any domain logic that acts on the data" --"saving and loading to the database" can credibly seen as one responsibility (more succinctly, persistence) but that "and also" introduces a completely separate responsibility.

I also don't like that the simplicity of most AR implementations -- the main benefit they seem to offer for that compromise of the SRP -- tends to rest on making additional compromises, mostly in DB design and use, but sometimes on the OO side. If you avoid those compromises, you end up with something that isn't any simpler to set up and maintain than a Data Mapper, and Data Mapper gives you more freedom to evolve the persistence implementation independently (even if the model is still usually closely parallel to the application model), and even use different types of datastores.

(On a note that does approach one of the issues raised upthread, its also a fact that real world DBs and OOPLs both often require pragmatic compromises to the natural abstract relational or OO models for a domain to optimally address real problems; while it would be ideal to choose better tools -- or improve the tools -- to avoid these problems, that's often not a practical option, and tightly coupling application and relational models means that that compromise you choose on one side gets reflected on the other side, where it may not be necessary, and may be counterproductive.)

Perhaps the problem the OP is referring to is code like

    foreach($things as $thing) {
      $thing->setValue('new value');
    } 

and then looping through 10000 rows to do that, instead of using an UPDATE query.

I think the best criticism of ActiveRecord (and ORM in general) is performance, but it's only relevant on medium-to-large websites. It is a fantastic design pattern for prototyping, and good enough for production on small-to-medium websites as long as there are caching layers above it.

Soooo one row of a collection represented as an object instance of a collection of instances is bad? Why?

No not at all :)

Slavishly mapping a row in a database table to an application object is bad. Off the top of my head, an example could be a Product, where the tables are something like:

    product - main product details
    product_option - options (e.g. Size, Colour)
    product_option_values - values for that specific option instance

In my application I don't care about the database structure - whether the tables are normalised or storing everything in one huge serialized blob (or CouchDB, or ElasticSearch or... you get the picture). Instead you want to get the options and save changes straight back when editing the product.

Now this is where my example breaks down as the Product needs to 'know' about what options are available (either to provide a nice API or to know what to display in the UI) and my schema doesn't allow for that (save a Product.getAllOptions() method) but I'll leave that as an exercise for my reader :)

Mainly how easy it is to have zero clue that you're doing something horrible (SQL performance wise). Not positive that's what parent meant, but that's my guess.

AR works nicely for simple basic queries but everything more advanced should be done with custom queries. That helps a lot :)

The issue is that the line between simple and advanced is blurry, especially for an inexperienced developer.

Maybe someday we (Royal we of all software engineers who build tools other engineers use) will learn there's a limit to abstraction layers applicability and put hard breaks into the code when that happens.

I guess one shouldn't complain, the more tools allow developers to shoot themselves in the foot and not feel the pain until the leg needs to be cut off, the more variety of positions that will be open for engineers who've been there done that.

Simple: CRUD operations

Advanced: Everything else

Sadly, it's not that cut and dry. Even what seems to be a simple CRUD retrieve operation to an inexperienced developer could be a very costly thing to do due to relationships between entities.