Duda MVC - Consultas SQL en Controlador

[GUILLHERMOSOFT]

Cordial Saludo

Llevo dos días laborando en mi nuevo empleo, en el cual se desarrolla con el Yii Framework, veo que hay quien escribe consultas SQL en el controlador e insite en que eso está bien, argumentando que en Yii los modelos no deben ser modificados, ante lo cual me siento un poco confundido ya que aunque nunca he trabajado con frameworks si he trabajado con MVC (de forma manual, yo mismo creo mis controladores, modelos y vistas), por lo cual me da muy mala impresión (considero que no es una buena práctica) la idea de escribir código SQL en un controlador, cuando se supone que en el MVC cada cosa tiene su lugar (esto con el fin de tener un código limpio y ordenado), por esto mismo escribo aquí, para conocer la opinión y concepto (frente a este tema) de quienes han desarrollado con este framework, ¿acaso Yii maneja una filosofía diferente ó soy yo quien está equivocado y está bien escribir consultas SQL en un controlador?.

Quedo atento a sus comentarios.

Muchas gracias por su atención.

[GatorV]

Estas correcto, no debe de haber consultas SQL en el controlador, todo eso pertenece al Business Logic de la aplicación (o sea el modelo) la idea es que del controlador simplemente consumas el modelo y lo pases a la vista, no tiene porque haber decisiones de lógica en el controlador para nada (o en su defecto las menos posibles).

[masterpuppet]

SQL en los controllers..., sin palabras, dudo mucho que los modelos no deban ser modificados y si así fuera la solución no es tener SQL en los controllers, es una forma muy pobre de manejarlo, no se como funciona Yii ni cuales son las recomendaciones pero entiendo que tiene un mix de AR + Table Data Gateway, teniendo esto en cuenta el SQL deberia ir en las clases que extiendan el AR + Table.

Saludos.

[GUILLHERMOSOFT]

Muchas gracias por su atención y comentarios, no puedo negar que me genera un poco de satisfacción al leer sus comentarios, en especial el de alguien como GatorV, si tienen algo más que aportar quedo totalmente agradecido.

[GatorV]

Te recomiendo este link: http://weblog.jamisbuck.org/2006/10/...ller-fat-model no es de PHP, si no de Ruby, pero el concepto se entiende, la idea es que tu controller sea lo más genérico posible para que responda ante múltiples requests.

Saludos.

[NUCKLEAR]

Podrías pedirle al compañero tuyo que se de una vuelta por acá y exponga sus argumentos. Quizá tenga una razón válida.

[carlos_belisario]

el problema viene de conceptos y muchos de los que realizan los framework también venden esto así, de hecho hay muchos tutoriales de Framework que indican que los modelos es solo para indicar la tabla de la DB y las relaciones, lo demas, consultas y la lógica es parte del controlador y es un error viendo lo que indica el patron MVC en su teoría y hace que los que estamos metiendonos con los Frameworks adoptemos este concepto aunque no sea correcto, por eso es importante de que antes de meternos con cualquier fw primero conozcamos las bases, saludos

[JairLizcano]

Es evidente que en la teoría que aplica a MVC no va, pero ten en cuenta que aún se mantiene la idea de la identidad (aquello, llámese como sea, que diferencia a algo de "otra cosa").

Cuando se hablaba de medios de clases se recurría a alejar toda función o propiedad que ligara su identidad, es decir; limitar una función, por ejemplo para este caso, con una consulta SQL que bien sabemos será relacionado con el objeto que a su vez no debería porque limita la función "editar"(o bien eliminar, insertar,..) a sólo una tabla en la base de datos y sus respectivos campos. y es ahí donde se mencionaban los medios de clases como solución, que es a lo que posiblemente tu colega hace elocuencia, aunque claro... es una razón justificable y no diría que primitiva.

Para el MVC es interesante plantear modelos por objetos, donde un modelo de determinado objeto es quien mantiene las diferentes consultas SQL o la parte ajena a la identidad de la clase. Generalmente ese modelo por objeto conserva como propiedad el objeto a quien afectan sus propiedades y funciones.

Que desde mi punto de vista y documentación, es lo que debería explicarle a tu colega.