Write haof XML files: Hari Seldon
(
hari.seldon@telefonica.net)
Fecha: lun 23 ene 2006 - 11:42:52 CET
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
[mailto:
info@simply-networks.de]
> 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
>
>
-- PHP Spanish Localization Talk Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Este archivo fue generado por hypermail 2.1.7 : sáb 18 mar 2006 - 18:23:29 CET