Aplicaciones de litio que van más allá de CRUD

Question

Esta es más o menos una versión centrada en el marco de un past Stack Overflow question, que trata acerca de cómo la mayoría del material introductorio en aplicaciones MVC tiende a presentar un acoplamiento ajustado entre modelos, vistas y controladores. Por ejemplo, tendrá una tabla de Usuario que será modificada por un controlador de Usuario que a su vez empujará los datos filtrados a una vista de Usuario. Tengo la impresión de que muchos frameworks MVC tienden a reflejar este patrón también. Todo está bien y bien para lo que es, pero en realidad nunca me lleva a nada más allá de construir y mostrar monótonas listas de cosas con un formulario HTML.

El framework MVC que se ve en este momento es Lithium, lo que parece bastante interesante como un estudio de caso de las técnicas de codificación de PHP5.3. En un extremo, Lithium tiene una clase Model que ofrece objetos envoltorios alrededor de tablas individuales y abstrae algunas consultas simples. Por otro lado, tiene una ingeniosa convención de enrutar URL a llamadas de método en objetos de controlador, que luego renderizan para mostrar plantillas.

Pero en medio de esto, me encuentro perdido en cuanto a dónde colocar toda la lógica interesante que relaciona los datos de la tabla A con los datos en las tablas de la B a la Z. O al menos, no estoy seguro dónde ubicar dicha lógica de una manera consistente con el diseño del marco. A mi entender, la abstracción de Lithium Model no hace mucho más que eliminar alguna repetición de nivel de fila/actualizar/eliminar, y la arquitectura de controlador/vista parece principalmente sobre la interfaz de usuario. No me gustaría poner mucha lógica de negocios en la misma clase Controller que está recibiendo llamadas de función enrutada de las solicitudes de URL.

Mi instinto sería llenar el vacío con un montón de mi propio código que existe más o menos por completo fuera del marco. No estoy seguro si debería esperar más que eso, pero dado lo rígidamente estructurado que todo lo demás está en Lithium, se siente de alguna manera insatisfactorio, como si hubiera podido rodar mi propio código de reducción sin la sobrecarga de asimilar la fuente de un gran marco.

¿Qué me falta aquí? ¿Existe una arquitectura o filosofía recomendada para usar este tipo de marco?

Answer 1

Una cosa que debes recordar con Lithium es que aún no hay una versión de producción preparada (aunque algunos sitios la están utilizando en producción). La principal característica que falta ahora es relaciones de modelo. Con las relaciones en su lugar, supongo que su pregunta será respondida en parte, ya que es un ladrillo importante en el panorama general de la creación de aplicaciones más complejas. Puede consultar la rama x-data donde el trabajo sobre las relaciones debe estar en curso.

Para la segunda parte de escribir la lógica del dominio, la respuesta simple es "en el modelo". Véase this (rather useless) example of extending model functionality por ejemplo. Otro ejemplo a tener en cuenta es la mini aplicación de código abierto Analogue, que es uno de los pocos ejemplos abiertos de trabajo de Lithium en uso. El Analogue model class muestra un modelo ligeramente más carnoso.

Y, finalmente, es una cuestión de conectar los puntos entre M, V y C. Un controlador de litio debería principalmente delegar trabajos en modelos, y tal vez reestructurar los datos de entrada si es necesario. Los ejemplos simples de tener un modelo de publicación, PostsController y views/posts/add, index, etc. no significan que simplemente deba tener Post :: all() allí. PostsController :: view necesita cargar un conjunto de modelos de comentarios probablemente.

¡Así que lanzará una gran cantidad de su propio código allí, por supuesto! De lo contrario, no sería una gran aplicación. Pero mantenga la lógica de dominio ligada al modelo donde sea natural.

• Necesitas verificar que la publicación del blog tiene un título único? Escribe un validador
• ¿Necesita asegurarse de que el usuario tenga acceso de escritura a la publicación? Anule el método de guardar y verifíquelo o filtéelo.

Pero creo que tenemos que esperar a que las relaciones aterricen y una versión 1.0 antes de poder juzgar por completo cómo se pueden resolver mejor las aplicaciones de estructuración en litio.