¿Desarrollos organizados?
17.Feb.2009 ~
6 Comentarios ~
902 Lecturas
Hubo un tiempo en el que empecé con un patrón que parecía el adecuado. El mini-fw que estaba empezando era como un billar: directorios estáticos por un lado, app por otro y el core como tercera banda -la más importante sin duda- donde trato de coleccionar -y reutilizar- funciones.
En la segunda entrega creamos el despachador de forma que todas las url's tenían que pasar por un index.php que controlaba todo el tráfico.
Y ahí se quedó el invento, al menos en lo que a publicaciones se refiere. En cuanto al código he avanzado bastante y pensaba que había seguido el camino correcto hasta que el maldito Apache Benchmark Tool se cruzó en todo esto.
Empecemos por el principio... el centro neurálgico de la aplicación es el index.php, por donde pasa absolutamente todo. En él, además de despachar las URLs hago bastantes cosas más. Defino los directorios de la aplicación, incluyo la configuración de la web, las funciones de base de datos, las funciones de lenguaje, de debug, cargo el idioma adecuado y como paso final -si existe y tiene buenas pintas- cargo el controlador asociado a la acción correspondiente.
En el controlador sigo haciendo varias inclusiones dependiendo de lo que tenga que hacer, puedo incluir funciones de paginación, de cache, de envío de correo, de tratamiento de feeds...
Despues de todo ésto, el controlador incluye al modelo y llama a la función correspondiente de base de datos, ésta función devuelve un array formateado de forma que -normalmente- no hay que retocarlo.
Como último movimiento, el controlador llama a varias vistas por defecto (header, lateral) a la vista correspondiente pasándole los datos recogidos en el modelo y al pie de página (footer).
Pero cuando empiezo a mirar las peticiones por segundo que es capaz de resolver mi estructura (#11# como máximo en un servidor que debería llegar a las 100) veo que algo falla, demasiados includes, requires, demasiada organización, demasiada modularidad, ¿demasiado mvc?...
¿El caché como solución?. Me vale pero en parte, si una aplicación funciona *bien* sin caché (hablo de llegar a cerca del nivel máximo de peticiones por segundo), con caché sería una especie de orgasmo. Pero no por contar con caché tenemos que plantear el desarrollo de forma errónea ¿no?.
Me pongo a buscar información por la Red y además de ésto (que no es poco, lectura recomendable) no encuentro gran cosa, todo el mundo está enamorado con los maravillosos Frameworks de desarrollo. ¿Acaso no queda nadie como yo?, ¿acaso a nadie le interesa tener control de código y recursos de su máquina?.
Así que aquí estoy, a las tantas, divagando de si me corto las venas o me las dejo largas -dicen que es la moda-. En fin, si alguien tiene la solución ideal... ideas are welcomed, mañana será otro día.
En la segunda entrega creamos el despachador de forma que todas las url's tenían que pasar por un index.php que controlaba todo el tráfico.
Y ahí se quedó el invento, al menos en lo que a publicaciones se refiere. En cuanto al código he avanzado bastante y pensaba que había seguido el camino correcto hasta que el maldito Apache Benchmark Tool se cruzó en todo esto.
Empecemos por el principio... el centro neurálgico de la aplicación es el index.php, por donde pasa absolutamente todo. En él, además de despachar las URLs hago bastantes cosas más. Defino los directorios de la aplicación, incluyo la configuración de la web, las funciones de base de datos, las funciones de lenguaje, de debug, cargo el idioma adecuado y como paso final -si existe y tiene buenas pintas- cargo el controlador asociado a la acción correspondiente.
En el controlador sigo haciendo varias inclusiones dependiendo de lo que tenga que hacer, puedo incluir funciones de paginación, de cache, de envío de correo, de tratamiento de feeds...
Despues de todo ésto, el controlador incluye al modelo y llama a la función correspondiente de base de datos, ésta función devuelve un array formateado de forma que -normalmente- no hay que retocarlo.
Como último movimiento, el controlador llama a varias vistas por defecto (header, lateral) a la vista correspondiente pasándole los datos recogidos en el modelo y al pie de página (footer).
Pero cuando empiezo a mirar las peticiones por segundo que es capaz de resolver mi estructura (#11# como máximo en un servidor que debería llegar a las 100) veo que algo falla, demasiados includes, requires, demasiada organización, demasiada modularidad, ¿demasiado mvc?...
¿El caché como solución?. Me vale pero en parte, si una aplicación funciona *bien* sin caché (hablo de llegar a cerca del nivel máximo de peticiones por segundo), con caché sería una especie de orgasmo. Pero no por contar con caché tenemos que plantear el desarrollo de forma errónea ¿no?.
Me pongo a buscar información por la Red y además de ésto (que no es poco, lectura recomendable) no encuentro gran cosa, todo el mundo está enamorado con los maravillosos Frameworks de desarrollo. ¿Acaso no queda nadie como yo?, ¿acaso a nadie le interesa tener control de código y recursos de su máquina?.
Así que aquí estoy, a las tantas, divagando de si me corto las venas o me las dejo largas -dicen que es la moda-. En fin, si alguien tiene la solución ideal... ideas are welcomed, mañana será otro día.
Comentarios
Un framework (hablo desde lo que conozco, no lo digo por todo los frameworks), lo unico que te da son soluciones para tareas a las que ya se ha enfrentado otra gente, y que se han solucionado en un alto porcentaje de ocasiones en comunidad. A esto se le aplican dos máximas muy importantes (al menos para mi):
1.- 10 ojos ven mas que 2, y 5 mentes piensan mas (y a veces mejor) que 1
2.- Esto es como aquello que suelen decir los maestros de artes marciales, por muy bueno que seas, siempre habra alguien mejor que tu. Esto no quiere decir que no tengas que hacer las cosaspor ti mismo, si no que en el entorno de un framework siempre encuentras gente que te echa un cable a la hora de solucionar un problema o a la que tu puedes ayudar a solucionar ese problema.
Piensalo bien, te crees qeu la gente detras de rails, django, symfony, etc etc etc no se preocupa del rendimiento?? pues claro que se preocupa, y optimizan todo el codigo todo lo que se puede.
Peeero, sigo diciendo que al final todo depende de ti.Si el framework es lo suficientemente flexible, te permitira hacer la app como tu quieras, haciendo las queries a db como tu quieras, llamando a las vistas, templates, etc como y cuando tu quieras y deshabilitando todo aquello que no necesites.
No se, es solo mi opinion, y ya me conoces que a mi me gusta eso de currarme las cosas por mi mismo, pero sinceramente, si en lugar de reescribirme de cero un modulo para gestionar feeds RSS puedo utilizar uno que hay en mi framework, y si algo no va bien o no me gusta, reescribirlo, colaborar, aportar.... pues mucho mejor :D
Ahora bien, si lo que quieres es hacer un codigo claro, limpio, reusable y que puedas compartir con una comunidad...
¿Y si no te gusta el comportamiento de ese FW en determinados contextos por lo que sea? (organización en disco, tipo de consultas SQL, metodología de programación). En ese caso o te adaptas a lo que hay o cambias buena parte del fuente para rehacerlo a tu gusto. Imagino que en parte también depende de lo exquisito que seas con todos estos factores. Hay a quien no le importa sacrificarlos.
Yo sigo viéndolo como usar Slackware o cualquier otra distribución con gestor de paquetes y resolución de dependencias automáticas. Llega un momento en el que pierdes el control de lo que estás haciendo.
De todas formas quiero creer que hay códigos claros, limpios, reusables y comunitarios que no tienen un FW detrás, piensa en todos los proyectos Open Source que hay -no basados en web- con mucho éxito a sus espaldas.
"pero hay ocasiones en las que las características específicas de un proyecto solamente la puedes sabes tú porque son eso, muy específicas."
Pero es que el framework no es el que va a programar por ti esas partes especificas, si no que vas a ser tu, utilizando (o no) las partes del fw que te puedan servir. La libertad de eleccion la tienes tu. De todas formas, por muy especifico que sea tu proyecto, en web, siempre tendras una capa de acceso a db, una capa de control de ui (con templates o lo que quieras) y cosas asi que, segun mi punto de vista, es tonteria rehacer si ya tienes buenas soluciones hechas.
Por ponerte otro ejemplo, tu en tus desarrollos en php usas adodb para acceso a la base de datos, no? (por que hacerte toda la capa de conexion y que sea independiente de la db por debajo y demás, igual es un poco desproporcionado). Peero, realmente necesitas adodb? no seria mejor planchar cuatro queries en un .php y listo? (claro, ahi tu evaluas y decides, igual es mejor, pero lo dudo, por que pierdes, entre otras cosas, flexibilidad.
"¿Y si no te gusta el comportamiento de ese FW en determinados contextos por lo que sea? (organización en disco, tipo de consultas SQL, metodología de programación). En ese caso o te adaptas a lo que hay o cambias buena parte del fuente para rehacerlo a tu gusto."
Me gustaria ver un ejemplo concreto de a lo que te refieres, pero lo que te puedo decir es que ahi, una vez mas, dependes del framework. Rails, por ejemplo, es super estricto en el tema de la organizacion del codigo. El te crea una estructura de directorios a la que tienes que ceñirte, meter los modulos de codigo en un sitio, las templates en otro, etc etc etc.
Django por ejemplo no lo hace asi. Tu empiezas el proyecto y tienes un dir con un par de ficheros .py de configuracion del proyecto (donde tu defines donde estan las cosas, entre otras opciones). luego te creas un dir para la app, en el que tienes 2 ficheros .py, uno para modelos y otro para vistas, y punto. A partir de ahi eres libre de hacer lo que quieras, donde quieras y como quieras (incluso no tienes por que tener el codigo ahi, si no que puede ser una app empaquetada como un egg de python que tienes instalado en el sistema.
Lo mismo para las queries. Tu tienes ahi un orm que automaticamente te genera queries optimizadas segun los parametros que quieras usar (http://docs.djangoproject.com/en/dev/topics/db/queries/#topics-db-queries). Que resulta que crees que tu puedes generar sqls mas optimizados, pues los generas y punto (http://docs.djangoproject.com/en/dev/topics/db/sql/#topics-db-sql), eres libre de hacer las cosas como quieras.
"Yo sigo viéndolo como usar Slackware o cualquier otra distribución con gestor de paquetes y resolución de dependencias automáticas. Llega un momento en el que pierdes el control de lo que estás haciendo."
JAJAJAJA, eso ha sido un golpe bajo... De todas formas no comparto esa opinion, me remito a lo dicho arriba, yo en django (y estoy seguro que en mil fw mas) puedo hacer las cosas a mi manera, sin romper nada de django. En una de esas "otras distros con gestor de paquetes" o usas ese gestor de paquetes, o acabas teniendo problemas de incompatibilidades a medio/largo plazo.
Yo creo que el tema es que tu ves los fw de desarrollo (ya sea web o de otro tipo) como algo que te fuerza a adaptarte a como hacen las cosas, mientras que yo lo veo como algo que te ofrece soluciones para problemas que te vas a encontrar y que puedes adaptar para tu proyecto :D
Miralo de esta forma: imaginate que tu mini-fw personal va creciendo, agregas varias funciones, me lo pasas, lo utilizo, le agrego varias funciones, se lo pasas a 3-4 conocidos mas que a su vez le agregan mas funciones y al final acabamos con un mini-fw bastante completo y montamos un proyecto open source sobre el y la gente empieza a usarlo... Es ese mini-fw menos eficiente que hacer las cosas a pelo desde cero? no deberia, no? por que lo hemos codeado para que sea lo mas eficiente posible...
"De todas formas quiero creer que hay códigos claros, limpios, reusables y comunitarios que no tienen un FW detrás, piensa en todos los proyectos Open Source que hay -no basados en web- con mucho éxito a sus espaldas."
Si, y yo no digo que haya que utilizar frameworks para todo (yo de hecho no lo hago), solo digo que no estoy de acuerdo con afirmar, de base, que por hacer las cosas sin un framework van a dar mas rendimiento, van a ser mas eficientes, etc.
Pero, ¿y si resulta que por complejos temas de optimización te ves en la obligación de analizar tu código hasta el mismísimo último punto y coma?
Ya sabéis la respuesta de lo que pasaría.
En el tema de usar o no un framework, abogo por usarlos cuando el rendimiento no sea un requisito esencial (en comparación... como usar C o ensamblador en lugar Java o .NET). Ricardo Galli tiene algunos artículos interesantísimos (con igualmente interesante discusión) en su antiguo blog (http://mnm.uib.es/gallir/posts/2006/09/26/820/, http://mnm.uib.es/gallir/posts/2007/04/13/1050/) en el que defiende el no-uso de frameworks ni de caché. Por otra parte, siempre está el regustillo de programar lo propio ("reinventar la rueda", que dicen algunos), la pega de la curva de aprendizaje o simplemente el interés de desarrollar tu propio framework con fines didácticos (más mi caso).
El caso es que los frameworks no son la panacea. Son eso, frameworks, entornos de trabajo que, si se amoldan a tu proyecto está genial usarlos, pero si no se amoldan puede ser un error usarlos... o usar uno mal escogido.
En fin interesante tema, me apunto este blog para leer más, entre tanto HOYGAN en la comunidad PHP se echa de menos buenos programadores y bloggers como tú ;-)
Un saludo.