reconozco que tu posicion esta bien fundamentada. Una de las cosas mas
va mi respuesta del servidor. Te lo cuento porque yo pensaba que me
proyecto determinado sin tener que usar un framework. Ahora que he
comenzado este proyecto grande he visto que es necesario.
Os cuento que el proyecto no es nada del otro mundo. Una pagina con un
index.php un par de clases y una base de datos. Asi comenzó todo y hasta
el ano pasado muy bien. Luego comenzaron los problemas (digo problemas
La integracion de los Clients fue lo primero que tuvimos que hacer.
Clients en IRIX,AIX,Windows. Nos tomamos un tiempo y vimos que era lo
hacia el puerto 80 y enviandole la informacion via POST a un script PHP.
muy logica. En el Controller.
pueden hacer desde el browser o desde una maquina via Socket. Asi le
queda al Controller decidir, que va a responder (nada solo un log).
En este ejemplo (solo pequeno) puedes ver como se puede aplicar el MVC.
mano. Creo que las personas que dicen (solo usando framework y usando
MVC). No me entiendas mal. Pienso que el uso de un Framework depende
mucho de lo que se vaya a hacer. Asi en cierta forma estoy de acuerdo
Bueno, yo personalmente no he trabajado (de momento) con ningún
framework en PHP.. Y no lo he hecho por mis propias razones.
La verdad es que programar dentro de un framework, te obliga a
programar como esté hecho ese framework.. Quieras o no.
Por ejemplo, Prado sigue el paradigma MVC (me resisto a llamarlo
patrón de diseño... Es un patrón arquitectónico en tal caso más que un
patrón de diseño); pues automáticamente tu aplicación deberá de seguir
este paradigma, y ello a veces no es "tan óptimo".
¿Por qué no es tan óptimo?; bueno, veamos, expliquemos rápidamente
qué es un MVC (para quién no lo conozca):
MVC son las siglas de Model-View-Controller. Normalmente en
cualquier aplicación OOP, se tienen varias clases que se comunican entre
sí; MVC intenta "estandarizar" esta comunicación. ¿Cómo lo hace? Pues
bien, divide la aplicación en un controlador (Controller), en el Modelo
(Model), y en Vistas (View); el controlador recibe las peticiones del
usuario, y con ellas decide que clase o clases instancia del modelo, esto
es, "refresca" el Modelo (el Modelo recibe las peticiones que le
corresponden); la parte del Modelo es la encargada de llevar la lógica de
la aplicación, esto es, conexión con base de datos, gestión de la
información, etc etc etc (y se refresca a si mismo en función de las
peticiones del Controller lógicamente, además de refrescar/mostrar las
Vistas). Por tanto, es la parte
"inteligente" de nuestra aplicación. Por último, las Vistas son lo que su
nombre indica... Vistas de "salida" -normalmente son de salida...-, como
resultado a las peticiones del usuario. Vamos, un listado de una
búsqueda, un formulario de edición de datos, ... Lo que se os ocurra.
La explicación es "chapucera", pero creo que la idea de MVC queda
más o menos clara.
El caso es que este paradigma viene de SmallTalk y del mundo Java; y
ahí funciona francamente bien, por cómo es la arquitectura de J2SE/J2EE;
y para una aplicación cliente/servidor tradicional, también funciona
francamente bien. Es una forma de programar elegante, muy bien
encapsulada, y muy extensible (daros cuenta que integrar vistas
diferentes es muy sencillo... Prácticamente no habrás de tocar el
controlador para nada, y el modelo tampoco, sino implementar tus vistas
nuevas; si implementas nuevas funcionalides, por fuerza has de tocar el
modelo, pero el controlador no sufriría más que los cambios necesarios
para redirigir las peticiones de las nuevas funcionalidades. Lógicamente
habría que desarrollara además las vistas que se necesiten para las
nuevas funcionalidades. Vamos, que hasta aquí muy bonito.
Pero una aplicación web en PHP, funciona un poco "diferente" a como
funcionan otro tipo de aplicaciones; veamos, un caso típico son las
aplicaciones que utilizan un index.php en el root del web, para después
realizar las operaciones que se necesiten. Por ejemplo:
Midominio.com?do=editUser&idUser=1
Podría ser una edición del usuario con la id 1
Pero lógicamente, esto llamaría a index.php...
El número de "acciones" que se pueden realizar en una aplicación web
compleja, son _bastantes_ (pensemos, simplemente, en listar, editar,
insertar, eliminar, o sea, 4 acciones diferentes, y multiplequémoslo por
el número de "información" que tengamos -usuarios, noticias, artículos,
imágenes, galerías.....) En definitiva, que salen bastantes acciones...
Y todas y cada una de ellas pasan por el index.php... Lo cuál, por
fuerza, "cargan" este archivo.
En una arquitectura Java, existe la ventaja de que el Controller
normalmente suele ser un Servlet que se encuentra instanciado en todo
momento, vamos, se instancia al arrancar el servidor web; en cuánto a una
aplicación cliente/servidor, sucede lo mismo, la instancia del Controller
va a iniciarse y morir con la aplicación; sin embargo, en una aplicación
en PHP esto NO ES ASÍ. Cada vez que llamemos a index.php, este se va a
instanciar en memoria, y vamos a forzar al Zend Engine a interpretarlo y
ejecutarlo; lógicamente, la parte de ejecución es común a cualquier caso;
pero no lo es la parte de la interpretación. Existen técnicas para
cachear el fichero "interpretado", pero suelen ser complejas... Con lo
cuál, a mi modo de ver, volvemos al principio.
Suponer una aplicación con unas 100 acciones diferentes, no es para
nada descabellado; y por cada una de las acciones, siempre siempre
estaríamos instanciando nuestro mismo Controller; y para cada acción, le
obligaríamos a hacer una "búsqueda" entre sus 100 acciones para realizar
lo oportuno; vamos, normalmente el index.php de una aplicación así
enfocada es un enooooooooorme switch case ;)
La ventaja evidente es que tengo centralizado la gestión de
peticiones; la desventaja, para mi, es que se vuelve menos óptimo de
forma exponencial a medida que aumente el número de
acciones/funcionalidades diferentes en nuestra aplicación.
Yo, particularmente, prefiero un enfoque más "segmentado", y lo que
suelo hacer es definir un "controller" por cada LEIE (listar, editar,
insertar, eliminar) que necesito en mi aplicación; así no tengo un
Controlador tan "grande" que instanciar, ni le hago trabajar tanto. Creo
que hay por ahí algún documento por la red de este enfoque, vamos, no me
lo he inventado yo... Pero me parece un enfoque muy interesante.
En otros thread de la lista, manteníamos este mismo "debate" con
Pablo Siciliano, y algún otro; Pablo comentaba que él adopta una
estrategia de MV (modelo-vista) y prescinde muchas veces del Controller;
es lógico el planteamiento, porque muchas veces el Controller es una
vista.. El caso más claro es un formulario de edición que hace submit
sobre si mismo (para indicar al usuario sobre el mismo formulario los
errores; si, ya se que con un include se puede solucionar también, pero
bueno, repito, son enfoques diferentes).
Volviendo al tema del framework, como comentaba, el utilizar un
framework determinado, me obliga a trabajar de una forma determinada,
leerme documentación acerca de cómo funciona el framework, y quizás no
ahorrar tanto tiempo como yo suponía.. O bien que la aplicación la esté
programando de una forma que a mi no me convence al 100 %; lógicamente,
si tengo en mente realizar varias aplicaciones con un mismo framework
durante un tiempo, digamos, por ejemplo, un año (o bien la misma....),
pues puede compensarme realizar un framework; pero lo habitual en una
aplicación en entorno web es que tenga un ciclo de desarrollo de máximo
unos 8-9 meses, más de ese tiempo... Malo, es que algo no va del todo
bien (lo habitual, al menos así lo entiendo yo, son 3-6 meses para una
aplicación de tamaño medio-grande; con el aumento de complejidad, han de
aumentarse los recursos
-desarrolladores-, pero no el tiempo de desarrollo, pues a más tiempo de
desarrollo, más "obsoleta" va a ser nuestra aplicación, y más tardamos en
cubrir las necesidades de nuestro cliente, con lo cuál probablemente este
tenga además de las necesidades iniciales, otras nuevas... Le estaremos
dando un producto "viejo", en mi opinión).
Bueno, vaya rollo que os he soltado... Es que hoy me he levantado
"filosófico", y me he puesto a escribir....
Pero creo que los puntos de vista que expongo, son para tener en
cuenta, y aunque quizás esten equivocados, creo que son interesantes... Y
motivo de un interesante debate si todos quereis participar en él ;)
Un saludo a todos :)
-----Mensaje original-----
De: carlos Medina
Enviado el: lunes, 23 de enero de 2006 9:53
Para: php-es@lists.php.net
Asunto: [PHP-ES] Re: Framework PHP
Hola Lista,
Como dijo Gustavo Prado, un framework es un marco de trabajo
en el cual
ya se encuentran muchas clases "precocinadas" para que el
programador de
sitios grandes tenga un instrumento medio standard para su
aplicacion(me
refiero a aplicaciones en la cual trabajen varios programadores).
En realidad la mayoria de los trabajos en PHP son muy "sencillos":
formularios, foros, rutina mail y otros. La mayoria de los
casos cuando
se comienza un proyecto, nunca se sabe bien, que tan grande
va a llegar
a ser. En estos casos se utiliza un framework para que el desarrollo
tenga ya desde su base una estructura en la cual el programador
(sobretodo el nuevo) pueda "entrar" al desarrollo con mas
facilidad y se
tenga una base de las clases mas usadas.
En un proyecto de gran alcance en el cual trabajo acualmente (combina
PHP, Java, JavaScript,PERL, C++ y ShellScript de integracion
en sistemas
linux, AIX, IRIX, Windows y MAC X) utilizamos el framework
seagull, que
segun el cliente es uno de los mas potentes pero al mismo tiempo mas
entendibles.
Cuando hay que desarrollar paginas nuevas o nuevos features
se tienen a
la mano una serie de herramientas como la conexion al DB
(independientemente de si es DB2, MySQL u ORACLE) con las
cuales manejo
los query sin tener que escribir el consabido "SELECT * FROM"...
A mi me gusta
Saludos
Carlos
Daniel Naranjo wrote:
Hola, disculpa mi ignorancia, pero para que sirve un
framework para php? actualmente desarrollo en php 4, pero no
entiendo muy bien el uso de un framework?
Salu2
Daniel
--
PHP Spanish Localization Talk Mailing List (http://www.php.net/)
To unsubscribe, visit:
http://www.php.net/unsub.php__________ Información de NOD32 1.1373 (20060120) __________
Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com
