Il pattern ActiveRecord segue / incoraggia i principi di progettazione SOLID?

Ci sono alcune critiche valide su ActiveRecord. Come sempre, Uncle Bob lo riassume perfettamente :

The problem I have with Active Record is that it creates confusion about these two very different styles of programming. A database table is a data structure. It has exposed data and no behavior. But an Active Record appears to be an object. It has “hidden” data, and exposed behavior. I put the word “hidden” in quotes because the data is, in fact, not hidden. Almost all ActiveRecord derivatives export the database columns through accessors and mutators. Indeed, the Active Record is meant to be used like a data structure.

On the other hand, many people put business rule methods in their Active Record classes; which makes them appear to be objects. This leads to a dilemma. On which side of the line does the Active Record really fall? Is it an object? Or is it a data structure?

Wikipedia riassume le critiche in una preoccupazione relativa alla testabilità :

In OOP the concept of encapsulation is often at odds with the concept of separation of concerns. Generally speaking, patterns that favor separation of concerns are more suitable to isolated unit tests while patterns that favor encapsulation have easier to use APIs. Active Record heavily favors encapsulation to the point where testing without a database is quite difficult.

Specificamente per l'implementazione di Ruby on Rails, scrive Gavin King (enfasi mia):

At this point, most developers are thinking um, ok, so how the hell am I supposed to know what attributes a Company has by looking at my code? And how can my IDE auto-complete them? Of course, the Rails folks have a quick answer to this question Oh, just fire up your database client and look in the database!. Then, assuming that you know ActiveRecord's automagic capitalization and pluralization rules /perfectly/, you will be able to guess the names of the attributes of your own Company class, and type them in manually.

Anche sull'implementazione di Ruby on Rails, John Januszczak scrive (sottolineatura mia):

PROBLEM #1: STATIC METHODS

...

Some would say using Static methods simply amounts to procedural programming, and therefore is poor Object Oriented design. Others would say static methods are death to testability.

PROBLEM #2: GLOBAL CONFIGURATION SETTINGS

...

Therefore there is no dependency injection on the Account class in my example, and by extension, on the Account instances. As we should all know by now, looking for things is very, very bad!

Altre risorse sul perché ActiveRecord e ORM sono generalmente considerati come anti-pattern:

• Rails disaccoppiamento del modello di dominio di Activerecord su StackOverflow,
• ORM è un anti-pattern
• Associazioni sporche con ActiveRecord
• Numero 23: Principi di progettazione SOLID sulla pratica di Ruby

ActiveRecord si è sempre sentito come un anti-pattern estremamente utile , ma sono d'accordo sul fatto che va contro l'SRP e in aggiunta al fatto che va contro il principio dell'inversione di dipendenza.

(presumo che la classe ActiveRecord sia implementata senza alcuna possibilità per l'integrazione delle dipendenze).

Dall'esperienza personale posso dire che il pattern ActiveRecord diventa un ostacolo principale per la scrittura dei test unitari. L'accoppiamento dello strato di persistenza e della logica di business in una singola "classe ActiveRecord" rende impossibile scrivere test di unità (a meno che non si sia prima il refactor). Pertanto, l'unica opzione è scrivere test di integrazione; e questo non è efficace quanto i test unitari. Questo diventa un problema importante soprattutto se si assume un progetto con un sacco di classi ActiveRecord; si traduce in test di integrazione altamente complicati e difficili da mantenere.

Quindi, ActiveRecord arriva praticamente contro SRP e crea qualche problema di manutenzione; sembra togliere il potere di scrivere test unitari.