Uno de los desarrollos que me han encargado últimamente es la ampliación de un portal desarrollado en CodeIgniter. Como buen programador freelance una de las cosas que me define es que disfruto cada vez que debo de acercarme a una nueva tecnología.
En este caso conocía el framework pero aún no había tenido la oportunidad de utilizarlo. Lo primero que diré es que es un framework con una cierta antigüedad, lo cual tiene ventajas y desventajas.
Implementa MVC (Model-View-Controller) lo cual es una buena noticia. La documentación es buena y de hecho recomiendo la lectura del tutorial de introducción donde podemos ver, mediante ejemplos prácticos, como funciona el framework, implementando páginas estáticas y una gestión de noticias contra base de datos.
Otra de las ventajas es que Internet está llena de información. Una búsqueda del nombre del framework en Stackoverflow nos devuelve 27.000 resultados, lo cual no está nada mal. También se puede interpretar como que CodeIgniter genera muchas dudas… pero quiero ser optimista 😉
El sistema implementa helpers, libraries y drivers. Estos últimos, una especie de librerías desarrolladas con programación orientada a objetos, lo cual permite posteriormente, desarrollar clases hijas que heredan de la clase madre y implementan funcionalidad concreta. Aparentemente, librerías mejoradas y con las ventajas de la OPP.
Se me ocurre que un buen ejemplo de utilización sería la implementación de un driver TPV genérico del cual heredarían clases hijas específicas para cada TPV concreto (Sermepa, Pasat, etc…)
En principio todavía es pronto para dar un veredicto final pero quiero destacar dos cosas que no me han gustado.
El sistema presume de utilizar el patrón de diseño Active Record de una forma particular pero incluso en la Wikipedia podemos ver que su implementación se aleja bastante de lo deseado. Personalmente soy un gran aficionado a este patrón, el cual conocí mientras desarrollaba con PEAR. En este caso no es cierto que el modelo lo implemente.
Por otro lado el enrutado debe ser definido en un array para cada una de las acciones de los controladores, lo cual da cierta flexibilidad, pero comparado con Zend, por ejemplo, pienso que pierde comodidad. En este último el funcionamiento es el contrario. Si se hace una llamada a una acción dentro de un controlador, el sistema busca dicha acción y simplemente se devuelve un error o la acción por defecto en el caso de no encontrar la acción. No necesitamos definir cada ruta para cada acción. Se hace implícitamente.
Desconozco si CodeIgniter plantea el enrutado así por una cuestión de performance pero entiendo que no debería de afectar. Si hago una llamada a un ruta es porque existe una acción que responde a ella.
Semanas después comprobé que se utiliza un enrutado estandar como en el resto de frameworks y que Codeigniter permite su personalización, también como en el resto. Información corregida 😉
Yo seguiré profundizando en la criatura… mientras tanto me gustaría conocer vuestra opinión. Ahí está la caja de comentarios 😉
Buenas, sólo aclarar que las rutas no son obligatorias de configurar. Por defecto, una ruta es site.ext/controlador/function. Sólo has de establecerlas si quieres que una ruta arbitraria apunte a un controlador concreto (por ejemplo, para hacer que site.ext/dd/mm/aaaa/nombreArticulo apunte, por ejemplo, al controlador posts funcion get y parámetro nombreArticulo
Hola Cobolero,
efectivamente esto es así. Lo descubrí poco después de escribir el post y no tuve tiempo de corregirlo.
Ya era raro que un framework tuviera este tipo de ‘limitaciones’.
Gracias por la aportación.
Abrazo
De nada 😉
Respecto al resto del artículo está bien y tienes razón en todo lo que dices.
Por ahí leí quejas sobre que el MVC que usa era muy laxo porque no obligaba a la inclusión de modelos (WTF???).
Sea como fuere estoy terminando un par de proyectos con este framework por medio y estoy bastante contento con él.
Próxima parada: Laravel