Contenido
Pregúnteme qué marco usar y probablemente tendré un momento de anciana gruñona y le diré que todos los marcos son tan malos entre sí. Lo que no quiere decir que todos sean malos, exactamente, pero en PHP tenemos una cantidad inimaginablemente grande de marcos (generalmente citados como N + 1, donde N es la cantidad de desarrolladores de PHP en el mundo), y probablemente todos tenían sentido. a la persona que los inventó.
Tener una opción de marcos probablemente sea mejor que intentar usar solo un marco, independientemente de lo que estaba tratando de construir exactamente, porque es el "mejor" (según la medida de "mejor"). Esta selección de ofertas de marco significa que puede elegir algo que satisfaga las necesidades del proyecto e incluso podría estar documentado. Los marcos en cualquier plataforma están realmente ahí para proporcionar estructura, módulos y bibliotecas reutilizables y, en general, evitar todas las tareas aburridas y repetitivas relacionadas con la construcción de la misma funcionalidad una y otra vez. Por ejemplo, al crear CMS, algo debería procesar y validar los campos del formulario por mí; si se deja en mis propios dispositivos, es posible que me pierda algo importante y prefiero hacer los elementos de cada proyecto que son diferente, en lugar de los que son iguales cada vez.
Marcos de pila completa
Los frameworks full-stack, como Zend Framework, pueden ser un buen lugar para comenzar para un desarrollador sin mucha experiencia en arquitectura. Ofrece una buena estructura para colgar una nueva aplicación y hay un buen "ecosistema" a su alrededor: muchos libros, tutoriales y también cierta documentación razonable. Si está tratando de construir una aplicación grande que será mantenida por mucha gente, entonces un marco popular y completo probablemente sea una buena opción, ya que dictará bastante estructura y será bien conocido y entendido.
Tener una estructura que ayude con la separación siempre es bueno; Al principio de mi carrera trabajé con algunos muy desarrolladores junior e intentó enseñarles el patrón MVC (Model View Controller), que era relativamente nuevo en ese momento. Tomamos la decisión de usar Smarty en la capa de vista; en parte para que los diseñadores pudieran trabajar con las plantillas más fácilmente, y en parte para que cuando alguien se acerque a mi escritorio y me pregunte "¿cómo hago X con Smarty?" Podría decir "¡no hagas X en la vista!" (nueve de cada 10 veces, esa fue la respuesta). Tener marcos nos ayuda a encontrar la misma separación en otras partes de nuestra aplicación. Muchos de ellos admiten la integración con una capa de plantillas como Smarty, o mi nuevo favorito, Twig, por lo que puede llevar esas herramientas con el marco que elija.
Aligerar la carga
Hay muchos marcos más livianos que Zend Framework, por ejemplo, trabajo bastante con CodeIgniter. ¿Es tan completo y robusto como Zend Framework? No, no lo es. Pero como marco auxiliar para permitir la creación de una aplicación rápidamente, es útil. En general, los marcos con menos funcionalidad de "ayuda" pueden ser más fáciles de encontrar, ya que es mucho más obvio cómo se unen las piezas. En un marco desconocido (para mí, eso es prácticamente todo), son los bits automágicos los que dificultan el trabajo y la depuración.
Ese sentimiento de estar "perdido en un nuevo marco" es inevitable y absolutamente frustrante; incluso un desarrollador experimentado se siente como un novato cuando no sabe cómo funciona nada. Si realmente tienes mala suerte, habrás elegido un marco cuyo canal de IRC te dirá que también eres un idiota. Es esta experiencia inicial muy negativa la que disuade a mucha gente de usar un nuevo marco o adoptar uno en primer lugar, y muy pocos marcos hacen un buen trabajo para ayudar a los nuevos usuarios a superar ese obstáculo inicial.
En PHP también tenemos algunos marcos que no son realmente marcos de la forma en que suelo usar la palabra. Tenemos algunos marcos de componentes encantadores; colecciones de bibliotecas diseñadas para usarse a voluntad y para jugar bien juntas, como Zeta Components (anteriormente eZ Components) y Symfony Components (¿has visto su sitio? ¡Ganan el premio a la mejor obra de arte!). El mejor y más subestimado de estos son, por supuesto, las propias ofertas de PHP PEAR y PECL; de alguna manera, se olvidan en este nuevo y valiente mundo de marcos.
Microframeworks
Los microframeworks son una tendencia emergente en PHP; estas son ofertas súper livianas que solo lo ayudan a unir las cosas más rápidamente. Un buen ejemplo es Slim, que es muy rápido y fácil de usar, y comprende los conceptos RESTful. Se basa en la idea de "rutas", que son patrones de URL. Registra una ruta y da una devolución de llamada que debe invocarse cuando se solicita esa URL.
La mayoría de los desarrolladores de PHP adoptan un marco y se apegan a él, o pueden usar uno en el trabajo y otro para su pasatiempo o proyectos de código abierto. Hay poco consenso sobre el "mejor" marco a utilizar, por lo que todo el mundo se apega a lo que sabe y el resultado es el desarrollo paralelo de un gran número de marcos. Me encanta tener una selección para elegir, pero ¿mencioné que todos son tan malos entre sí?
Si conoce Zend Framework, terminará describiéndose a sí mismo como un desarrollador de Zend Framework; no se sentiría cómodo escribiendo en otro marco hasta que haya tenido la oportunidad de familiarizarse con él, y probablemente no recuerde muchas de las funciones PHP sin procesar para las cosas si no las usa con frecuencia. Esta idea de que nos hemos convertido en desarrolladores específicos de frameworks, que solo trabajamos sobre capas de abstracción, es un poco extraña para PHP. Después de todo, este es el lenguaje "para resolver el problema de la web". Está escrito en C y es un lenguaje rápido y ligero en sí mismo ... ¡siempre que no espere a que se ejecute un gran proceso de arranque de marco! De este contexto surgió el Manifiesto MicroPHP, escrito por un hombre al que llamamos Funkatron (aunque en realidad se llama Ed Finkler). Es una serie de declaraciones que dicen que está bien construir varios módulos pequeños interoperables, que más grande no es mejor y que, en realidad, la vida es demasiado corta para Java, incluso si está escrito en PHP.
