Tag Archives: php

WordPress y los ataques DoS

De aquí a un tiempo he visto algunos scripts bastante simples que, sorprendentemente, hacen bastante daño a malas configuraciones de sitios con wordpress. El sistema de DoS (Denial of Service, Denegación de Servicio) que se usa para el ataque es de tipo flood (inundación) enviando un número muy alto de peticiones. Por ejemplo: Under Security.

Normalmente, estos scripts se realizan buscando las peticiones más lentas de los sistemas web. Una vez detectadas, se procede a lanzar muchas de estas peticiones en muy poco tiempo. Los servidores web, ante una avalancha de peticiones, normalmente, comienzan a crear forks o workers (según el servidor y modo de funcionamiento) hasta llegar al límite máximo configurado… o a que se sature el sistema y termine no respondiendo.

Los sistemas GNU/Linux, al igual que la mayoría, tienen un uso de memoria limitada por el tamaño de la misma que haya instalada. Estos sistemas manejan una caché bastante grande y por ello, aunque se tenga 1GB o más instalado en el sistema, siempre se anda con una ocupación bastante alta de la memoria del sistema. Cuando esta se agota, se recurre a la memoria de intercambio (swap), que es mucho más lenta que la memoria convencional, por lo que el sistema comienza a ralentizarse.

Para evitar estos problemas, lo ideal es configurar de forma adecuada el servidor web, acorde a la memoria disponible, el número máximo de hilos que se puedan crear y el número máximo de forks o workers que se puedan lanzar para atender peticiones. Con esto evitamos que la memoria se use en exceso y, aunque las peticiones se atiendan más lentas, se asegure que el sistema permanecerá estable.

También habría que revisar la pila de entrada TCP para el puerto 80 (se puede ver a través de netstat en cualquier sistema GNU/Linux), por si acaso se saturase mucho, comenzar a cortar, vía cortafuegos (iptables), las direcciones IP que estén haciendo flood.

Los sectores del software

De siempre, se va viendo que las empresas de software se decantan por una forma de hacer las cosas, mientras que otras eligen otro camino distinto y, muy pocas, mezclan elementos de doctrinas tan establecidas y dogmáticas como son: el mundo del software libre, el mundo java o el mundo .net.

El mundo .NET

Como todo lo que tiene que ver con Microsoft, el mundo .NET se mueve, casi exclusivamente, con productos y herramientas desarrolladas por esta misma compañía. Funciona sobre Windows, con base de datos de Microsoft y se diseña con herramientas de Microsoft.

Lo bueno de Microsoft es que desarrollan los productos para un público general y sin conocimientos extensos. Los lenguajes suelen ser o muy fáciles (Visual Basic) o muy complejos (C++, C#), pero cumplen con todas las necesidades de los programadores a los que van dirigidas las herramientas. Así mismo, tienen un alto nivel de operatibilidad entre los diferentes productos, es decir, escribir código ASP con SQL Server es simple, gracias a ese nivel de compactación y simplificación.

Lo bueno de la simplificación lleva a lo malo de la complejidad también. Un programa que se hace de forma simple y fácil, siguiendo los pasos que Microsoft ha pensado para dar es simple, sencillo y rápido. Pero cuando la aplicación debe tener una forma específica o salirse un poco del camino típico, comienzan a surgir problemas solo saldables con código complejo.

Ximian, absorbida por Novell, ha realizado muchas aproximaciones a este mundo para portarlo al mundo del software libre a través de su escritorio Gnome y su proyecto Mono. No obstante, es un tema un poco espinoso, ya que quien usa software libre, por lo general, se aleja de las tecnologías propuestas por esta gran multinacional, por lo que, aunque es usada y tiene su cuota de mercado, Mono no llega a ser usado tanto como podría esperarse.

El mundo Java

El mundo de Java ha estado siempre en una lucha constante y abriéndose camino en el desarrollo de software, sin mucho éxito al principio, sobre todo en lo que respecta a las aplicaciones de escritorio. Esto fue debido a su naturaleza de pseudo-compilación y pseudo-interpretación, ya que es un lenguaje compilado e interpretado que se ejecuta sobre una máquina virtual, y las labores de interpretación de los bytecodes son algo costosos, en relación a código que se ejecuta de forma nativa.

No obstante, en la parte web, de interfaces, desde que comenzó, ha tenido una gran aceptación, puesto que permite el desarrollo de las aplicaciones en cualquier infraestructura (windows, linux, solaris, …) y se han desarrollado grandes herramientas para el desarrollo en este sentido.

Java siempre es el favorito y preferido de las consultoras (a menos en España), donde es empleado para el desarrollo de aplicaciones, tanto de escritorio como web en todos los sectores donde son contratados.

La mayoría de empresas que han tenido relación con Microsoft y han salido de malas con la grande, han terminado montándose al carro de Java y aportando a esta comunidad en modo de open source herramientas, conocimiento, etc. Además de Sun Microsystems (su fundadora), hay otras como IBM, RedHat, Oracle, etc. que se han sumado al carro de Java para el desarrollo y ampliación de esta comunidad.

Hay comunidades de software libre que se han sumado a la aportación de código para el mundo Java. Esto supongo que será erróneamente aportado como el voto útil, sin saber que en nada se beneficia al software libre en sí, sino solo al mundo Java que, aunque pueda parecer atractiva la idea de luchar contra el tirano, no es más que ayudar a una empresa a derrocar a otra. Esto puede ser muy discutible, sobre todo por los defensores de Java :-D

El mundo del software libre

Al margen de la guerra entre .Net y Java, surgen los entornos, sistemas y elementos de software libre. Pensar que todo el mundo tiene que ser Java o .Net es un craso error, ya que hay muchos elementos que se pueden combinar a gusto propio del desarrollador y emplearlos como mejor convenga para obtener los mejores resultados para una tarea concreta.

A este respecto, una de las comunidades con más auge es la de desarrolladores de PHP, por ejemplo, que es el lenguaje que más proyectos de software libre tiene desarrollados, y es el más usado para el desarrollo de sitios como Facebook, Menéame, WordPress, etc.

Otra de las comunidades más activa en los entornos web es la de Ruby, Ruby on Rails más específicamente, que tiene un entorno fácil y profesional para el desarrollo rápido de sitios web. También Python, con su framework Django. Ambos presentes en el mundo Java a través de JRuby y Jython, respectivamente.

Entornos también desarrollados en lenguajes más específicos como Perl, Erlang, Tcl, etc. hacen que se complete el abanico de posibilidades para el desarrollo de software a través de las soluciones que aporta el software libre.

La nota negativa, es que los elementos no son altamente cooperativos, es decir, aunque se basan en estándares, normas y todos son abiertos, hay que realizar desarrollos para poder tener funcionando cosas entre unos y otros, debido a que en el software libre, no todo está hecho o viene dado fácilmente. Pero la nota positiva sobre esto, es que la dificultad que eso entraña es mucho menor que la que entrañaría el desarrollar algo no hecho o no pensado para hacerse, en Java o .Net.

Conclusión

En principio, no te quedes solo con uno, esto no son tres equipos a los que haya que apoyar a muerte, estas son tres formas de ver la tecnología y puede convenir cualquiera de las tres según el contexto en el que haya que ponerse.

Por ejemplo, en una empresa que se haya invertido en infraestructura y software Microsoft, se tenga todo montado en SQL Server, con ASP e interfaces desarrolladas en Visual Basic, desarrollar cualquier nueva ampliación o una nueva herramienta, cabe pensar que será siempre más fácil si nos ceñimos a lo ya establecido que si comenzamos a cambiar lo que hay.

Igualmente, en otra empresa en la que se haya realizado una inversión para Java, incluso con servidores Solaris, y bases de datos Oracle, no conviene pensar en desarrollar nada con Visual Basic, ni PHP, sino pensar en agregar más aplicaciones de tipo J2EE, que será lo más fácil de implementar.

Por último, en una empresa pequeña, con aspiraciones a crecer, que tengan todo desarrollado en PHP y MySQL, se podría cambiar a un framework de desarrollo para PHP, así como agregar elementos más complejos en caso de ser necesarios (como memcached).

En definitiva, no intentar cambiar lo que ya hay si funciona. Otro caso es que no funcione o que haya que realizar adaptaciones y se pueda aprovechar para agregar elementos más generales o estándares.

PHP 5.3

Llego algo tarde, cosas del verano, pero voy a comentar algunas de las mejoras que vienen incluidas en la nueva liberación de PHP, la 5.3.

Para mi, esta versión, además de corregir fallos de la anterior, aporta características que le hacen acercarse aún más a la forma de programación profesional que viene dada con otros lenguajes como Java, C#, C++, Python, Ruby…

Espacios de nombres (namespaces)

Los espacios de nombres, llamados en otros lenguajes: paquetes, módulos, …; con esto, podemos tener organizado nuestro código, no solo en directorios, sino también bien delimitado su espacio de nombres mediante el uso del namespace.

Por ejemplo, si tenemos dos directorios: File y BD; que pertenecen a un programa y cada uno de ellos tiene un archivo para contener la clase Output, en las versiones anteriores de PHP habría que incluir uno u otro, o modificar el nombre para que fuese FileOutput y DBOutput, redundando la ruta con el nombre de la clase.

Ahora, con el uso de namespaces, se puede delimitar con solo agregar una sección de código como esta:

namespace File {
 
    class Output {
        /* ... */
    }
}
 
namespace {
    $f = new File\Output();
}

Static… ahora sí

En las versiones anteriores de PHP, los valores static no eran tratados del todo bien, no permitiéndose algunos usos que parecían lógicos y no produciéndose, sobre todo en la herencia, los resultados que se esperaban.

Ahora, ya se permite el uso de variables para contener el nombre de la clase a la que llamar de forma estática, es decir, ya se permite este uso:

class A {
    public static function say() {
        echo "Hola\n";
    }
}
 
$clase = "A";
$clase::say();

Así mismo, el uso del late state binding, es posible mediante la palabra clave static, de modo que, si se llama a un método estático como static::metodo() en lugar de como self::metodo(), se llama al método de la clase hija que haya sobrecargado al método que se llama. Un ejemplo:

class A {
    public static function who() {
        echo __CLASS__;
    }
    public static function test() {
        static::who(); // Here comes Late Static Bindings
    }
}
 
class B extends A {
    public static function who() {
         echo __CLASS__;
    }
}
 
B::test();  // output: B

Por último, la función especial __call no se llama cuando no hay un método de clase que no exista, en su lugar se llamará a __callStatic, de modo que se pueda hacer diferencia de cuando se está llamando a un método de objeto y cuando se llama a un método de clase.

Más de Late State Binding

Hasta ahora, cuando se quería hacer una clase abstracta que llamase a funciones de sus clases hijas, que aún no han sido declaradas, éstas debían ser abstractas. Pero si la clase no era abstracta y el método a llamar no constaba como abstracto, la llamada no se realizaba a esa función, sino a la del padre.

El sistema de late state binding, asegura que la llamada a métodos se hará siempre de abajo a arriba, es decir, si existe un método en la clase hija que se instanció, aunque el método en ejecución sea el del padre, el método que se llama es el de la clase hija. Más o menos lo que se vió con los métodos estáticos, pero esta vez con métodos.

Funciones anónimas

El uso de funciones anónimas (closures o lambda) es una técnica de programación que permite completar código escrito, mediante el desarrollo parcial de algún algoritmo. Imagina que quieres hacer un código en el que tengas que hacer algo, un paso inicial, un paso intermedio y, en cada iteración una ejecución específica, para terminar con un último paso tras esa iteración.

El código concreto dentro de la iteración puede variar… y de hecho variará en cada implementación, pero el resto no, el resto se mantiene de forma fija. Pues, se puede implementar el esqueleto del programa, y aceptar como parámetro de la función que se haga, una variable que contenga el código a ejecutar. La función que completaría nuestro código se puede hacer así:

$code = function ($dato1, $dato2) {
    echo $dato1 . "--" $dato2 . "\n";
};
 
algoritmo($code);
 
function algoritmo( $func ) {
    for ($i=0; $i<100; $i++) {
        $func($i, $i*$i);
    }
}

También se pueden emplear funciones como array_walk, preg_replace_callback, uasort, etc.

Esto permite realizar códigos como los que se realizan en Ruby o en los lenguajes funcionales y declarativos.

Recolector de Basura de Referencias Circulares opcional

Se deja al programador la decisión de si quiere activar el recolector de referencias circulares del garbage collector, o no. Por defecto viene activado y actúa de la siguiente forma, con este código:

class A {
    function __construct () {
        $this->b = new B($this);
    }
}
 
class B {
    function __construct ($parent = NULL) {
        $this->parent = $parent;
    }
}
 
for ($i = 0 ; $i < 1000000 ; $i++) {
    $a = new A();
    unset($a);
}
 
echo number_format(memory_get_usage());

Si se ejecuta desde consola, con una versión de PHP anterior a la 5.3, se verá en pantalla un error fatal, de que el límite de memoria se ha superado.

Esto es debido a que la liberación de memoria, cuando se va a proceder a liberar la clase B, ve que tiene una referencia a A, que ya va a ser liberada y crea un ciclo, con lo que, para evitarlo, no libera B. En las versiones de PHP 5.3 en adelante, se detecta este ciclo como tal y se liberan ambas.

También existe la posibilidad de desactivar este comportamiento o ver si está activo, con las funciones gc_enable, gc_enabled y gc_disable.

Nowdoc y Heredoc

Hasta ahora, los bloques de tipo heredoc eran los únicos que permitían escribir de forma libre un texto para después usarlo como variable. Ahora también disponemos de los nowdoc, que son iguales, salvo que no se hace parseo de variables. Un ejemplo:

$hola = "Hi, ";
 
$hd = < <<END
texto $hola
END;
 
$nd = <<<'END'
texto $hola
END;
 
echo $hd; // output: texto Hi,
echo $nd; // output: texto $hola

Constantes

Ahora, la palabra clave const puede ser empleada fuera del alcance de una clase, con lo que, en lugar de usar define se puede emplear esta forma:

// antes
// define("CONSTANTE", "Hola mundo!");
 
// ahora
const CONSTANTE = "Hola mundo!";

Operador Ternario simplificado

El operador ternario (expr1)?(expr2):(expr3) ahora permite dejar vacío el espacio correspondiente a (expr2) de modo que si (expr1) es verdadero, se retorna (expr1) y si es falso, se retorna (expr3).

Nuevos Módulos

PHPar

Al igual que JAR, PHPar sirve para empaquetar los PHP en un solo fichero, con lo que se mejora el despliegue de las aplicaciones, la organización del código, etc.

Intl

Mejores funciones de internacionalización para PHP. Hasta ahora, en PHP el único soporte de internacionalización que había disponible era gettext, ahora, con el uso de Intl y sus clases, se facilita internacionalizar una aplicación web, ya que tiene soporte para numeración, fecha, etc.

FileInfo

Da información sobre ficheros, usando la cabecera magic del propio fichero, intenta localizar de forma heurística su tipo, pudiendo retornarlo en formato MIME.

Etiquetas de Salto

Bueno, como en todo, hay avances y retrocesos, esto de proporcionar a PHP un elemento de código spaguetti como es el goto, no hace sino potenciar los malos usos, por lo que yo descartaría su uso.

Migración

Como cualquier liberación de lenguaje, PHP viene con mejoras, agregados y, además, cambios que implican que códigos anteriores puedan dejar de funciona, con lo que es aconsejable leerse bien la guía de migración, para ver los cambios que se introducen, lo que llega a ser deprecated, etc.

Conclusiones

Con esta liberación, PHP da varios matices que le hacen acercarse más a lenguajes como C++ y Java, agregando cosas como PHPar y los namespaces, así como mejorando su implementación de POO.

Considero que el cambiar a esta versión y desarrollar con las nuevas implementaciones hará que los códigos desarrollados sean más claros y, sobre todo, más organizados, por lo que es una buena baza para realizar el cambio.

Además, viendo la guía de migración, se deja entrever que los cambios de la versión anterior, 5.2.x, a esta nueva rama, son mínimos, con lo que, si se ha desarrollado código acorde a la versión anterior, realizar los cambios para adecuarse a esta versión, no es nada complicado.

Ruby para programadores de PHP

Mi amigo Dani me indicó una página, ya que estamos más metidos en Ruby on Rails, que nos permitiría tener un sitio de referencia y comparación con las cosas, tal y como las hacíamos en PHP, cómo hacerlas ahora en Ruby on Rails.

Rails For PHP Developers
Derek DeVries, Mike Naberezny; Pragmatic Bookshelf 2008

La idea es muy buena, la página, en inglés, se llamada railsforphp. Los autores tienen también un libro publicado por la editorial Pragmatic Programmers, una editorial con un contenido bibliográfico que, en mi opinión, está alcanzando o superando en calidad a los contenidos que suele presentar y presenta O’Reilly.

En la página se ven secciones, si se busca alguna función específica de PHP o de Rails, se puede ver la forma de uso equivalente en PHP, y cómo se haría en Ruby on Rails. Da consejos y admite comentarios. Quitando que el diseño está muy trabajado, la presentación y secciones, son muy parecidas a la página de referencia de PHP.

Lenguajes: nuevas versiones

En estos últimos días he visto los nuevos lanzamientos, o lo que se espera lanzar en varios “mundos” del desarrollo del software. Por un lado, hay varios puntos donde la interfaz pasado-futuro corre bastante peligro.

Los desarrolladores de ciertos lenguajes han creído conveniente romper con el pasado de uso de dichos lenguajes para acogerse a los progresos y prácticas más usadas actualmente. Haremos repaso.

Perl 6

El lanzamiento de esta versión de Perl ha traído de cabeza a varios programadores, en algunos sitios ya existen guías de migración de Perl 5 a Perl 6 a modo de poder ayudar a los programadores a pasar a esta nueva versión y aprovechar sus nuevas características. Entre ellas, cabe destacar:

  • Tipificación
  • Parámetros en subrutinas
  • Orientación a Objetos
  • Comparaciones encadenadas
  • Evaluación perezosa
  • Macros

Larry Wall mencionó que la versión 5 era su reescritura de Perl, su visión de cómo debía de ser y que, la versión 6, debía de ser la reescritura de Perl para lo que quiera que sea la comunidad.

PHP 6

La versión de PHP 5, trajo consigo una orientación a objetos muy mejorada. Pero aún hoy, con la versión 5.2 estable y la 5.3 en inestable, se echa en falta una versión más completa del lenguaje, características avanzadas como las que se encuentran en otros lenguajes como Ruby, Java, Python o C++.

Por ello, la versión de PHP 6, nos aportará mejoras considerables como:

  • Closures y lambda
  • Traits
  • Namespaces
  • Más mejoras en la orientación a objetos

Por otro lado, hay que mencionar que esta versión ya no asegura la compatibilidad hacia atrás, es decir, con scripts programados para versiones de PHP 3.x, 4.x o incluso algunas del 5.x.

Python 2.6 y 3.0

El último lanzamiento de la versión 2.x se hizo con la versión 2.6, la cual incluye características y corrección de fallos, además herramientas para migrar a la versión 3, e incluso comenzar a usar elementos específicos de la versión 3 incluídos en la 2.6, a través del comando future.

La versión 3.0 de Python rompe también la interfaz pasado-futuro al no ser compatible con la rama anterior a nivel de scripts. No obstante, se han incluido herramientas para facilitar su transición.

Las mejoras incluidas:

  • Print es una función
  • Views e Iterators en lugar de Lists
  • Nueva sintaxis de anotaciones, argumentos y literales
  • Cambios en las librerías estándares (reorganización)

Conviene realizar una migración y estudiar un poco los cambios, si se desea realizar el salto a esta nueva versión.

Ruby 1.9.1

El comentario más sonado sobre esta versión es: el más rápido que la 1.8; y es que, parece que, aún no habiendo cambiado mucho la forma del lenguaje, sí han cambiado los procedimientos internos para hacerlos más óptimos.

Lea las características para más información.

Conclusiones

Aprender un lenguaje no es una seguridad en cuanto a dejar de aprender se refiere. Dentro de cada uno de los lenguajes de programación existentes, se han observado cambios patentes que se realizan con una periodicidad de pocos años, con lo que es bueno mantenerse al tanto de las nuevas versiones, otros lenguajes y, sobre todo, las necesidades y entornos, sus progresos y cómo se adaptan los lenguajes a ellos, puesto que determinarán si estamos eligiendo adecuadamente nuestra herramienta de trabajo o no.

PHP no es para todo

La popularización de los lenguajes de programación, hace que muchas veces, una aplicación que se desarrolló en otro lenguaje, sea portada a ese nuevo lenguaje, para demostrar su potencia, sencillez o capacidades.

Algunas veces, esos nuevos lenguajes, resultan ser muy buenas herramientas que nos permiten trabajar más rápido sin necesidad de centrarnos mucho en problemas típicos y ya salvados desde hace tiempo (como las cadenas de texto y los tamaños de memoria han sido un gran problema a la hora de escribir programas en C/C++).

Lenguajes como Perl, PHP, Python, Tcl, Ruby… son lenguajes que no requieren de compilación, tienen un nivel de programación muy alto y no suelen estar ligados a una plataforma concreta, con lo que el mismo código puede ejecutarse sin problemas en otras plataformas (Windows, GNU/Linux, BSD…), su código es muy fácil de escribir y, en pocas líneas, se hacen muchas operaciones.

No obstante, cabe recordar que, los lenguajes que se escriben con particularidades específicas y especiales, suelen servir de forma muy óptima y potente a esas particularidades, pero de forma contraria, e incluso ser un lastre, en otros entornos de la programación.

Como ejemplo, tal y como dice el titular, PHP, que nació para la web, ahora se emplea como lenguaje de scripting para la consola e incluso con GTK para generar scripts fáciles que permitan automatizar el equipo. Pero, PHP no es para todo, y con esto quiero decir que PHP tiene sus pequeñas limitaciones.

Una aplicación en GTK o en un entorno de ventanas, por ejemplo, debe de tener capacidad multihilo y capacidad para compartición de memoria entre dichos hilos. PHP carece de ello. Es normal, la web no requiere estos mecanismos.

Al igual que para la rápida detección de ciertos tipos de texto y conversión de formatos o cálculo de datos en formato CSV se ha empleado siempre Perl, y ahora se comienza a emplear también Ruby, en línea antecesora del uso de herramientas dispersas como sed, awk y shell script. PHP también se emplea para estos cometidos, pero no es óptimo para ello, puesto que su núcleo de ejecución no está optimizado para una sola ejecución, sino para una repetición de ejecuciones secuenciales y/o paralelas.

Si comparamos la velocidad de ejecución de PHP y Perl, veremos que Perl se ejecuta casi tan eficientemente como C, puesto que está pensado para tareas de administración de sistemas y automatización de tareas, mientras que PHP no requiere de ello para su tarea cotidiana, que es la web, donde el intérprete de PHP no tiene que cargarse en cada ejecución, sino que permanece cargado a espera de ser llamado.

Pero, al igual que PHP no es para todo, los demás también tienen sus limitaciones. Por ejemplo, Perl se ha usado históricamente como CGI, mientras que Perl no es óptimo para la web en sentido de que PHP es más rápido en este contexto (gracias a técnicas de caché y aceleradores que se integran en el motor de Zend), más fácil de desarrollar y mantener.

MVC en PHP, ¿es correcto?

Después de haber realizado una investigación sobre el tema, he hallado una serie de enlaces, donde se destacan cosas como que el único MVC oficialmente creado es phpMVC, o cosas como que MVC no es para PHP.

En principio, buscando alternativas, además de phpMVC tan solo encontré Kenda, el cual se encuentra en un estado muy inicial y con muy poco apoyo.

Hay personas como Jim Lim, creador de ADODB, que consideran mala idea el portar MVC a PHP, sobre todo porque parece ser que nadie sabe aún como debería de hacerse. En su blog, Jim, señala seis puntos para los que MVC suele fallar:

  1. Control centralizado sobre los derechos y accesos a la página
  2. Habilidad para remapear URLs debido a cambios en la estructura web
  3. Manejar inteligentemente errores 404
  4. Habilidad para, dinámicamente, añadir cabeceras y pies a páginas para mostrar alertas tales como “sistema se apagará a las 5:00″
  5. Separar el contenido de la presentación de una forma razonable, ej. con plantillas.
  6. Administración de datos “manchados” (ej. GET, POST, COOKIES)

Con estas premisas, nos queda investigar un poco en, ¿qué es exactamente MVC? y así podremos responder la pregunta que motiva este artículo.

M: Modelo, es la lógica de negocio, es decir, toda función que nos permite extraer datos, ya sea de una base de datos, con proceso intermedio o sin él.

V: Vista, es la presentación de la aplicación. Se basa en tomar los datos con los que se tiene que formar una presentación y conformar el documento, ya sea HTML, WML, XML o cualquier formato de salida hacia el usuario.

C: Controlador, es la parte que une a la lógica de negocio o modelo con la presentación o vista. Se encarga del transporte de datos entre uno y otro y de hacer de interacción con la entrada del usuario, sistema, periféricos, etc.

En este respecto, sobre el Modelo tenemos ADODB, que nos permite abstraernos de la base de datos para preocuparnos solo de la lógica de negocio propiamente dicha, es decir, los algoritmos que se necesitan para procesar los datos.

En la vista tenemos varias optativas, una de ellas es el uso de Smarty. Esta librería ofrece una conversión de etiquetas al estilo XML dentro de un documento de plantilla HTML, lo cual sirve para que el diseñador realice la página de plantilla sin problemas y, el programador, utilice la misma, u otras, sin variar su código.

En la vista también es usual el uso de XML/XSLT. La salida hacia el navegador se realiza en XML teniendo en cuenta solo la organización de los datos que se deben enviar al cliente y, una hoja de transformación (XSLT) se encarga de transformar ese fichero XML en un fichero HTML, WML.
La parte del controlador es algo más crítica y, a su vez, la más importante. En los proyectos phpMVC y Kenda, lo que se ofrece es, justamente, esta parte en forma de frameworks. No obstante, siempre está la opción de hacerlo uno mismo, puesto que PHP en sí, contiene suficiente funcionalidad en su API como para realizar la gestión de todo lo que realiza el controlador de forma asequible.

Bueno, después de haber tratado más ampliamente el tema, ¿es correcto el uso de MVC en PHP? a lo que podemos responder que sí, si el proyecto es grande y requiere de una clara división de Modelo y Vista (programadores y diseñadores) pero a su vez es simple y, no, si el proyecto es pequeño o con muchos matices complejos de gestión de accesos, permisos y control de fallos desde el servidor.

¿Qué opináis?