Estoy barajando la posibilidad de migrar el entorno de la empresa en la que trabajo de Codeigniter a otro framework más robusto como Symfony2 o Laravel.
En realidad lo único que usamos de Codeigniter es la estructura MVC y algún que otro helper que hemos desarrollado.
También queremos cambiar el paradigma de programación a POO ya que ahora no estamos haciendolo.
Además las consultas a la base de datos de mysql (muy complicadas en algunas ocasiones) las hacemos directamente en SQL.
Antes de seguir planteándonos la migración de framework y de paradigma de programación queremos saber si, dado que la base de datos siempre va a ser mySQL, es posible omitir el uso del ORM y hacer las consultas en mySQL tradicional, o al menos en parte. La cuestión es que a veces realizamos consultas bastante complejas y que también son utilizadas por otro personal de la empresa que simplemente las ejecuta para obtener estos datos y poder tratarlos para distintos informes. Entiendo que si hacemos las consultas a través de un ORM tendríamos que hacer doble trabajo (la misma consulta en sql y en el lenguaje del ORM), a parte de tener que aprender el lenguaje específico del ORM.
¿Creeis que ya que vamos a tener que empezar a aprender desde cero un framework es mejor hacerlo en Symfony que tiene más documentación que Laravel?
Es difícil evaluar lo que realmente necesitas sin saber exactamente todos los datos y seguro que no hay una solución perfecta, partiendo de eso te comento:
No tienes que pensar en el ORM cómo una simple traducción tabla -> objeto. Piensa más bien en datos objetos, por que digo esto, porque tal vez tu base de datos o consultas es tan compleja cierta lógica de esta deba estar en la base de datos.
Por ejemplo, imagina que uno de los datos que necesitas sacar son los clientes cuyos proveedores tienen cuentas en países con moneda dollar. Ahí hay mucho join, una consulta con muchas tablas, y además está el detalle que tu dices, cuando cambio de framework u orm tengo que volver a traducir, pues bueno, si ya sabes que partes de esa complejidad, puedes:
- Dejar la lógica de los datos en la base de datos. Usar vistas, stored procedures, functions...
- Hacerte una capa de datos a medida independiente a la que atacarán los modelos.
- ...
En el segundo punto hay una cosa interesante, una cosa es el modelo y otra el mapeado de los datos en objetos, el modelo es la parte que nos abstrae de donde vienen los datos. Por ejemplo, en el caso de lo que usáis ahora, un modelo de ci te puede ofrecer un método users->getRows(), esas filas pueden proceder de una consulta a la base de datos, un petición a un REST o un array, pero el controlador no se entera.
Que quiero decir con lo anterior, que aunque no optes por usar un ORM cómo doctrine o eloquent, si que es bueno usar modelos, y si usas vistas por ejemplo, puedes hacer el mapeado a la vista con lo cual la complejidad se queda en la base de datos y el mapeado en el orm que uses siempre será sencillo.
Resumiendo:
- (MySQL (view, sp, funtions)) -> ORM -> Model -> Controller.
- (MySQL) -> Data layer -> Model -> Controller
- MySQL -> ORM -> Model -> Controller
Seguro que hay más opciones, son las que alguna vez he usado y conozco. Piensa también que por suerte tanto Doctrine cómo Eloquent no son cómo el query builder de codeigniter, puedes usarlos en otros frameworks, son simplemente paquetes, de hecho los puedes usar en codeigniter también, con lo cual si empezaras en symfony y después quisieras pasar a Laravel podrias continuar usando Doctrine.
Sobre que framework elegir, depende de cuan complejo sea el proyecto y es muy opinable, desde luego sea cual sea la elección yo usaría un framework con el que puedas crecer y que sea actual, cosa que no pasa con codeigniter. Te pongo un ejemplo de tipos de proyectos y que framework elegiría:
- ERP (Muchos módulos que deben interactuar y compartir información) -> Symfony.
- Típico Backend - Frontend -> Laravel, Yii2, SimpleMVCFramework (Ojo con estos puedes evolucionar hasta un Symfony, es una opción para proyectos que en pricipio parecen más simples pero no te puedes pisar los dedos)
- Servidor REST, blog... -> Silex, Slim.
Espero haberte ayudado algo en la toma de tu decisión. Un saludo.
Te recomiendo Symfony. Si quieres hacer tus querys SQL en crudo no vas a tener problema. Puedes crearte un repositorio para tu entidad, y en los métodos hacer la consulta que quieras y devolver los objetos con el formato que necesites.
Estoy barajando la posibilidad de migrar el entorno de la empresa en la que trabajo de Codeigniter a otro framework más robusto como Symfony2 o Laravel.
En realidad lo único que usamos de Codeigniter es la estructura MVC y algún que otro helper que hemos desarrollado.
También queremos cambiar el paradigma de programación a POO ya que ahora no estamos haciendolo.
Además las consultas a la base de datos de mysql (muy complicadas en algunas ocasiones) las hacemos directamente en SQL.
Antes de seguir planteándonos la migración de framework y de paradigma de programación queremos saber si, dado que la base de datos siempre va a ser mySQL, es posible omitir el uso del ORM y hacer las consultas en mySQL tradicional, o al menos en parte. La cuestión es que a veces realizamos consultas bastante complejas y que también son utilizadas por otro personal de la empresa que simplemente las ejecuta para obtener estos datos y poder tratarlos para distintos informes. Entiendo que si hacemos las consultas a través de un ORM tendríamos que hacer doble trabajo (la misma consulta en sql y en el lenguaje del ORM), a parte de tener que aprender el lenguaje específico del ORM.
¿Creeis que ya que vamos a tener que empezar a aprender desde cero un framework es mejor hacerlo en Symfony que tiene más documentación que Laravel?
Un saludo.
10/11/2015 01:09
Es difícil evaluar lo que realmente necesitas sin saber exactamente todos los datos y seguro que no hay una solución perfecta, partiendo de eso te comento:
No tienes que pensar en el ORM cómo una simple traducción tabla -> objeto. Piensa más bien en datos objetos, por que digo esto, porque tal vez tu base de datos o consultas es tan compleja cierta lógica de esta deba estar en la base de datos.
Por ejemplo, imagina que uno de los datos que necesitas sacar son los clientes cuyos proveedores tienen cuentas en países con moneda dollar. Ahí hay mucho join, una consulta con muchas tablas, y además está el detalle que tu dices, cuando cambio de framework u orm tengo que volver a traducir, pues bueno, si ya sabes que partes de esa complejidad, puedes:
- Dejar la lógica de los datos en la base de datos. Usar vistas, stored procedures, functions...
- Hacerte una capa de datos a medida independiente a la que atacarán los modelos.
- ...
En el segundo punto hay una cosa interesante, una cosa es el modelo y otra el mapeado de los datos en objetos, el modelo es la parte que nos abstrae de donde vienen los datos. Por ejemplo, en el caso de lo que usáis ahora, un modelo de ci te puede ofrecer un método users->getRows(), esas filas pueden proceder de una consulta a la base de datos, un petición a un REST o un array, pero el controlador no se entera.
Que quiero decir con lo anterior, que aunque no optes por usar un ORM cómo doctrine o eloquent, si que es bueno usar modelos, y si usas vistas por ejemplo, puedes hacer el mapeado a la vista con lo cual la complejidad se queda en la base de datos y el mapeado en el orm que uses siempre será sencillo.
Resumiendo:
- (MySQL (view, sp, funtions)) -> ORM -> Model -> Controller.
- (MySQL) -> Data layer -> Model -> Controller
- MySQL -> ORM -> Model -> Controller
Seguro que hay más opciones, son las que alguna vez he usado y conozco. Piensa también que por suerte tanto Doctrine cómo Eloquent no son cómo el query builder de codeigniter, puedes usarlos en otros frameworks, son simplemente paquetes, de hecho los puedes usar en codeigniter también, con lo cual si empezaras en symfony y después quisieras pasar a Laravel podrias continuar usando Doctrine.
Sobre que framework elegir, depende de cuan complejo sea el proyecto y es muy opinable, desde luego sea cual sea la elección yo usaría un framework con el que puedas crecer y que sea actual, cosa que no pasa con codeigniter. Te pongo un ejemplo de tipos de proyectos y que framework elegiría:
- ERP (Muchos módulos que deben interactuar y compartir información) -> Symfony.
- Típico Backend - Frontend -> Laravel, Yii2, SimpleMVCFramework (Ojo con estos puedes evolucionar hasta un Symfony, es una opción para proyectos que en pricipio parecen más simples pero no te puedes pisar los dedos)
- Servidor REST, blog... -> Silex, Slim.
Espero haberte ayudado algo en la toma de tu decisión. Un saludo.
17/11/2015 12:48
Muchas gracias por tu comentario.
La verdad es que nos ha ayudado mucho y he decidido darle caña a Symfony.
La idea en principio es aprender bien el framework y luego ya decidiremos si utilizamos Doctrine o no.
Muchas gracias por todo.
24/11/2015 07:28