Yo creo que en el tema c y ahora en el tema frameworks hay un concepto que surgió por simple y llanamamente por necesidades de la vida (antes había una empresa que quería soft y lo pagaba a precio de oro, hoy son muchas y ninguna quiere ni pagar) lo que se conoce como 'tiempos de desarrollo' ;)
Si tu haces una aplicación en menos tiempo eres más productivo, y por ello ganas más dinero, y tienes más tiempo libre (o por lo menos es lo que se espera). Por eso en su momento como dice el compañero c se comió a ensamblador, vb a c, php a perl, y hoy rails a php poco a poco (y si no miraros gráficas de uso de rails de un año para aquí) ... No por que sean mejores, sino porque aceleraban el desarrollo. Por otro lado quien sería capaz de realizar en una semana una aplicación web con soporte i18n, acl, cache, que funcione en php4 y php5, etc desde cero? Que levante la mano y que le mande curriculum al core de cake ;) Además si queremos rendimiento hablar de php (o ruby, o asp, o java) ... mal empezamos ... Pero quien se plantea no usar hoy en día en entorno web lenguajes interpretados? Yo creo que nadie, ni ibm. Aquí entramos en tema de caché tanto de php con aplicaciones con apc, eacelerator, memcache, como en mysql (donde está muchas veces la clave para los cuellos de botella). El día 5/03/08, rcechang <[EMAIL PROTECTED]> escribió: > > > Estoy de acuerdo con minskog, en que automatizar tareas tienen un > costo. Y no es solo a la base de datos (MySQL o la que fuere) puesto > que por ejemplo en la automatización de Joins también hay un proceso > de armado de las consultas mediante código por decir algo. > > En otras palabras si, por ejemplo, respondemos a la pregunta ¿qué es > más rápido leer un archivo .php que accede directamente a la base de > datos o hacerlo a través de un Model de cakePHP? la respuesta es casi > obvia. Pues para que cakePHP funcione primero tiene que pasar por el > dispatcher, luego tiene que resolver los routes, luego tiene que > llamar al controlador, el controlador llama al modelo (¡por fin!), y > de ahí renderiza la vista, y devolver el resultado al usuario. Y en el > camino, ocurrieron muchas otras cosas "ocultas" (como por ejemplo, > seleccionar el Model apropiado, que si hubo uno en la carpeta de mi > aplicación o no, etc.). > > La ventaja para el programador: le facilitó la vida. La computadora > hizo el trabajo por él. > Pero vamos ¿es esto malo? eso depende que quieres hacer. En tiempos en > que nació el C y luego C++ se le achacaban críticas de que era lento > (comparado con el código de máquina, claro está, porque comparado con > otros lenguajes es rapidísimo). La ventaja de C, que facilitaba la > vida al programador. Hoy se vería como una locura escribir un programa > por ejemplo de gestión en assembler. Ahora, que si el rendimiento es > crítico, todavía se pueden escribir partes específicas en assembler e > integrarlo al C. > > Volviendo a cakePHP ¿qué puede tener problemas de rendimiento? sí, > como cualquiera. > Ahora. Hacer aplicaciones "grandes" no es una tarea para cualquiera. > Eso se hace en equipos y equipos preparados y hay que evaluar muchas > variables (como ya se dijo, el entorno, por ejemplo). Pensar que > porque uno puede construir una casa, ya está preparado para construir > un edificio, es falso. ¿Qué Zend está mejor preparado para > aplicaciones "grandes"? En mi opinión Zend es de más bajo nivel (de > programación, insisto, no hablo de la calidad) y por tanto mas > flexible, pero te da más trabajo. En las manos apropiadas eso puede > ser bueno. En las manos no apropiadas, eso puede traer más problemas y > casi con seguridad menor rendimiento (en una aplicación grande) que > cakePHP. > > Pues nada. En conclusión. Depende de muchas cosas y no se trata solo > de decir, que no está preparado para esas cosas. > > Ahh, lo olvidaba. Efectivamente el tema del cache es algo importante > al hablar de rendimiento. > > Saludos > > > > --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "CakePHP-es" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a CakePHP-es@googlegroups.com Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/CakePHP-es?hl=es. -~----------~----~----~----~------~----~------~--~---
