Rails Desacoplamiento del modelo de dominio de Activerecord

Question

He estado leyendo el libro "Antipatterns de SQL: evitar las trampas de la programación de bases de datos", especialmente en torno al patrón anti de beans mágicos. En él se muestra un diagrama que desacopla los registros activos usando un modelo de dominio y tiene un ejemplo en PHP, pero no Rails, se refiere a esto como una agregación HAS-A entre los modelos de dominio y las vistas/controladores y la composición HAS-A entre los modelos de dominio y los registros activos (I supongo que esto es UML habla).

En Rails, parece ser un lugar común para hacer modelos de grasa de controladores ligeros mediante el uso de métodos modelo, estos métodos pueden manipular otros modelos asociados de modo que solo se pueda usar un modelo en cualquier controlador dado. Sin embargo, me pregunto si existe una práctica que incluya un desacoplamiento total en Rails.

Es decir, para crear un modelo sin tablas u otra clase para usar como modelo de dominio que actúa como una capa entre controladores y objetos Activerecord (que a su vez están asignados a tablas) para que los controladores tengan un mejor aislamiento y no necesita saber algo sobre la base de datos subyacente y su estructura. También da la opción de alejarse de los métodos CRUD que no explican los requisitos de la aplicación que aplican, otra crítica en el libro.

Answer 1

Mis comentarios provienen de la utilización de DDD junto con ASP.NET MVC. El enfoque recomendado para vincular controladores a entidades de dominio es a través de modelos de vista, que son DTOs destinados específicamente a unirse a una vista específica. El modelo de vista proporciona un búfer muy necesario entre los mecanismos de vinculación y el modelo de dominio. A menudo, una vista dada puede ser una composición de múltiples entidades de dominio o incluso objetos de informes y, por lo tanto, no se corresponde directamente con ninguna entidad de dominio determinada. Tener los atributos necesarios para una vista declarada en un modelo de vista hace que esos requisitos de datos sean explícitos y no los lleva a intentar ajustar el modelo de dominio para satisfacer las necesidades de una vista.

La desventaja, por supuesto, es el potencial surgimiento de una jerarquía de doble clase, donde puede tener un modelo de vista que corresponde a muchas de sus entidades de dominio. Sin embargo, en la práctica, encuentro que mantener la jerarquía de clases duales es mucho más fácil que preocuparse por las ramificaciones de cambiar una entidad de dominio. Eche un vistazo al The Fallacy of ReUse.

En un sistema SOA, los objetos que ven los modelos 'wrap' pueden no ser entidades de dominio sino DTOs que representan esas entidades de dominio. Esto no viola la estructura de los modelos de vista, ya que ellos mismos son DTO y no tienen aspectos de comportamiento, solo datos. Eche un vistazo al artículo this que analiza la naturaleza de los datos en los límites de la aplicación.

Para responder a su pregunta, creo que la creación de una capa de vista de modelos sería ventajosa para una aplicación de Rails, teniendo en cuenta todas las advertencias anteriores. Los modelos de vista se llenarían con datos de un objeto de registro activo o de cualquier otro objeto que contenga datos para ser presentados, y luego cuando el usuario ingrese datos, el modelo de vista actualizaría el objeto de registro activo o la entidad de modelo de dominio. Aunque evitaría llamar a esta capa de modelo de vista un modelo de dominio.

Answer 2

Puede encontrar útil esta aplicación basada en Rails: https://github.com/qertoip/guru_watch - tiene como objetivo mostrar cómo desacoplarse de ActiveRecord de la manera recomendada por Robert C. Martin. Se conoce como arquitectura de caso de uso o diseño de entidad-control-límite.