activerecord como modelo, ¿es esta una buena idea?

Question

Recientemente, gracias a la popularidad de los rieles, muchas personas comienzan a usar activerecord como modelo. sin embargo, antes de saber de los rieles (mi grupo no era fanático de las cosas de código abierto, nos enseñaron en una escuela .NET) y mientras estaba haciendo mi proyecto de último año, encontré esta definición para un modelo

El modelo representa los datos empresariales y las reglas comerciales que rigen el acceso y las actualizaciones de estos datos. A menudo, el modelo sirve como una aproximación de software a un proceso del mundo real, por lo que se aplican técnicas simples de modelado del mundo real al definir el modelo.

no dice que el modelo debe representar una tabla como lo que activerecord hace. Y normalmente dentro de una transacción, uno puede tener que consultar algunas tablas no relacionadas y luego manipular datos de diferentes tablas ... así que si activerecord se usa como modelo, entonces cualquiera de los dos tendría que meter todo el código lógico en el controlador (que es un poco popular en algunos marcos php) que hace que sea difícil probar o piratear el modelo activerecord para que realice la operación de la base de datos no solo en la tabla a la que se asigna, sino también otras tablas relacionadas ...

entonces, qué ¿Es tan bueno abusar (en mi humilde opinión) activerecord como el modelo en un patrón arquitectónico MVC?

Answer 1

Martin Fowler describió este patrón en Patrones de arquitectura de aplicaciones empresariales junto con otros dos patrones o arquitecturas. Estos patrones son buenos para diferentes situaciones y diferentes cantidades de complejidad.

Si solo quieres cosas simples, puedes utilizar Transaction Script. Esta es una arquitectura que viste en las antiguas páginas ASP y PHP donde un único script contenía la lógica de negocios, la lógica de acceso a datos y la lógica de presentación. Esto se desmorona rápidamente cuando las cosas se vuelven más complicadas.

Lo siguiente que puede hacer es agregar un poco de separación entre la presentación y el modelo. Esto es activerecord. El modelo aún está vinculado a la base de datos, pero tiene un poco más de flexibilidad porque puede reutilizar su modelo/acceso de datos entre vistas/páginas/lo que sea. No es tan flexible como podría ser, pero dependiendo de su solución de acceso a datos puede ser lo suficientemente flexible. Los frameworks como CSLA en .Net tienen muchos aspectos de este patrón (creo que Entity Framework se parece demasiado a esto también). Todavía puede manejar una gran cantidad de complejidad sin volverse inmanejable.

El siguiente paso es separar su capa de acceso a datos y su modelo. Esto generalmente requiere un buen mapeador O o mucho trabajo. Entonces, no todos quieren ir por este camino. Muchas metodologías como el diseño impulsado por el dominio persiguen este enfoque.

Por lo tanto, todo es una cuestión de contexto. ¿Qué necesitas y cuál es la mejor solución? Todavía utilizo la secuencia de comandos de transacción a veces para el código simple de un solo uso.

Answer 2

Lo mejor de usar los Rails ActiveRecord como modelo en MVC es que le ofrece un ORM (Object Relational Mapper) automático y una manera fácil de crear asociaciones entre los modelos. Como ha señalado, a veces puede faltar MVC.

Por lo tanto, para algunas transacciones complejas que involucran muchos modelos, sugiero usar un Presentador entre su controlador y sus modelos (Rails Presenter Pattern). El presentador agregaría sus modelos y lógica transaccional y sería fácilmente comprobable. Definitivamente desea esforzarse por mantener toda su lógica de negocios en sus modelos o presentadores, y fuera de sus controladores (Skinny Controller, Fat Model).

Answer 3

He dicho muchas veces que usar Active Record (o ORM, que es casi lo mismo) que Business Models no es una buena idea. Permítanme explicar:

El hecho de que PHP es de código abierto, gratis (y toda esa larga historia ...) le proporciona una vasta comunidad de desarrolladores que vierten código en foros, sitios como GitHub, código de Google y más. Puede ver esto como algo bueno, pero a veces tiende a no ser "tan bueno". Por ejemplo, supongamos que se enfrentan a un proyecto y desea utilizar un marco ORM para hacer frente a su problema escrito en PHP, bueno ... usted tendrá un montón de options to choose for:

• Doctrina
• Propel
• Qcodo
• Letargo
• Redbean

y la lista sigue y sigue. Los nuevos proyectos se crean regularmente. Así que imagina que has construido un framework completo e incluso un generador de código fuente basado en ese framework. Pero no colocó clases de negocios porque, después de todo, "¿por qué escribir las mismas clases otra vez?". El tiempo pasa y se lanza un nuevo marco ORM y desea cambiar al nuevo ORM, pero tendrá que modificar casi todas las aplicaciones cliente usando referencia directa a su modelo de datos.

La línea inferior, registro activo y ORM están destinados a estar en la capa de datos de su aplicación, si los mezcla con su capa de presentación, puede experimentar problemas como este ejemplo que acabo de establecer.

Hear @ Mendelt's wise words: Read Martin Fowler. Ha puesto muchos libros y artículos sobre el diseño de OO y ha publicado algunos buenos materiales sobre el tema. Además, es posible que desee consultar Anti-Patterns, más específicamente en Vendor Lock In, que es lo que sucede cuando hacemos que nuestra aplicación dependa de herramientas de terceros. Finalmente, escribí la publicación del blog this hablando sobre el mismo problema, así que si quieres, échale un vistazo.

Espero que mi respuesta haya sido de alguna utilidad.