Me interesa saber si el patrón ActiveRecord, hecho famoso por Ruby on Rails, fomenta o desalienta el uso de SOLID principios de diseño.
Por ejemplo, me parece que los objetos ActiveRecord contienen lógica de dominio y lógica de persistencia, que es una violación de la responsabilidad única.
Hay algunas críticas válidas en ActiveRecord. Como siempre, Uncle Bob lo resume perfectamente :
El problema que tengo con Active Record es que crea confusión acerca de estos dos estilos de programación muy diferentes. Una tabla de base de datos es una estructura de datos. Ha expuesto datos y ningún comportamiento. Pero un registro activo parece ser un objeto. Tiene datos "ocultos", y comportamiento expuesto. Puse la palabra "oculto" entre comillas porque, de hecho, los datos no están ocultos. Casi todos los derivados de ActiveRecord exportan las columnas de la base de datos a través de accesores y mutadores. De hecho, el registro activo está destinado a ser utilizado como una estructura de datos.
Por otro lado, muchas personas ponen métodos de reglas de negocios en sus clases de Registro Activo; Lo que los hace parecer objetos. Esto lleva a un dilema. ¿En qué lado de la línea cae realmente el Registro Activo? ¿Es un objeto? ¿O es una estructura de datos?
Wikipedia resume las críticas en un problema de comprobabilidad :
En la POO, el concepto de encapsulación a menudo está en desacuerdo con el concepto de separación de preocupaciones. En términos generales, los patrones que favorecen la separación de preocupaciones son más adecuados para pruebas de unidades aisladas mientras que los patrones que favorecen la encapsulación tienen API más fáciles de usar. Active Record favorece en gran medida la encapsulación hasta el punto en que las pruebas sin una base de datos son bastante difíciles.
Específicamente para la implementación de Ruby on Rails, escribe Gavin King (énfasis mío):
En este punto, la mayoría de los desarrolladores piensan um, ok, entonces, ¿cómo diablos se supone que debo saber qué atributos tiene una empresa al mirar mi código? ¿Y cómo puede mi IDE completarlas automáticamente? Por supuesto, la gente de Rails tiene una respuesta rápida a esta pregunta. ¡Oh, simplemente inicie su base de datos de clientes y busque en la base de datos! Luego, suponiendo que conoce las reglas de capitalización y pluralización automáticas de ActiveRecord / perfectamente /, podrá adivinar los nombres de los atributos de su propia clase de empresa y escríbalas manualmente.
También en la implementación de Ruby on Rails, John Januszczak escribe (énfasis mío):
PROBLEMA # 1: MÉTODOS ESTÁTICOS
...
Algunos dirían que usar métodos estáticos simplemente equivale a una programación de procedimientos, y por lo tanto es un diseño pobre orientado a objetos. Otros dirían que los métodos estáticos son la muerte a prueba.
PROBLEMA # 2: CONFIGURACIÓN GLOBAL DE CONFIGURACIÓN
...
Por lo tanto, no hay inyección de dependencia en la clase de Cuenta en mi ejemplo, y por extensión, en las instancias de la Cuenta. Como ya deberíamos saber, ¡buscar cosas es muy, muy malo!
Algunos recursos más sobre por qué se considera que ActiveRecord y ORM son un antipatrón:
ActiveRecord siempre se sintió como un anti-patrón extremadamente útil , pero estoy de acuerdo en que va en contra de SRP y adicionalmente en contra del principio de inversión de dependencia.
(Supongo que la clase ActiveRecord se implementa sin ninguna posibilidad de inyección de dependencia).
Por experiencia personal puedo decir que el patrón ActiveRecord se convierte en un obstáculo importante para escribir pruebas unitarias. El acoplamiento de la capa de persistencia y la lógica empresarial en una sola "clase ActiveRecord" hace que sea imposible escribir pruebas unitarias (a menos que se refactorice primero). Por lo tanto, la única opción es escribir pruebas de integración; y eso no es tan efectivo como las pruebas unitarias. Esto se convierte en un problema importante, especialmente si asume un proyecto con muchas clases de ActiveRecord; da como resultado pruebas de integración muy complicadas que son difíciles de mantener.
Por lo tanto, el ActiveRecord viene bastante en contra de SRP y crea un dolor de cabeza de mantenimiento; Parece que le quita el poder a escribir pruebas unitarias.
Lea otras preguntas en las etiquetas object-oriented ruby-on-rails