¿Tiene sentido evitar un marco al construir una gran aplicación web con PHP?

Siendo un desarrollador de aplicaciones web PHP desde hace varios años, he tenido mi parte de MVC y frameworks. Al principio pensé que eran lo mejor desde el pan rebanado; Todo parecía ser muy fácil de implementar.

Ahora, sin embargo, parece que cuanto más compleja se vuelve la aplicación, más complicaciones presenta el marco, por lo que tengo que desarrollar soluciones alternativas para superarlas. Tales soluciones suelen ser bastante desalentadoras y complejas, ya que tengo que profundizar en el código central del marco y hacer cambios para que se comporte de la manera que quiero.

Por ejemplo, en uno de mis proyectos donde uso Slim (C) + Idiorm (M) + Twig (V) (que creo que es muy flexible), tengo que crear una función personalizada solo para mostrar datos dinámicos en las plantillas principales; sin un marco podría simplemente haber ejecutado mysql_query () en el archivo incluido.

De acuerdo, los marcos son geniales si estoy creando un sitio web de perfil de empresa simple; Puedo crear un poco de código en una noche y generalmente están listos por la mañana, y la cantidad de buenas prácticas de codificación y patrones de diseño que he aprendido de ellos es muy valiosa.

Pero en realidad, para una aplicación web compleja como un sistema de administración escolar todo en uno basado en la web, los marcos generalmente se interponen en el camino de mi proceso comercial como en el ejemplo anterior.

Entonces, mi pregunta es: ¿está bien volver a lo básico y usar código PHP estándar y bibliotecas para hacer mi próximo proyecto, donde podría haber miles de marcos y bibliotecas, siempre que pueda usar suficientemente las buenas prácticas de codificación y seguir patrones de diseño sensibles? como MVC? Mi equipo de desarrollo es bastante pequeño: solo 2 programadores y 1 diseñador. El otro programador está de acuerdo con mis pensamientos anteriores.

Mi experiencia es casi lo opuesto a la tuya. Al hacer cosas pequeñas y rápidas, un marco puede "interponerse" un poco, ya que necesita diseñar su código de cierta manera y pensar en las cosas cuidadosamente antes de continuar. Simplemente saltando directamente a mysql_queryusted puede tener su prototipo en funcionamiento mucho más rápido.

Pero para sitios grandes y complejos, es extremadamente importante diseñar cuidadosamente el código y realmente pensar en cómo escribir su código si desea un sitio que se pueda mantener en el futuro.

En particular, agregar mysql_queryllamadas a partes aleatorias del ciclo de la página generalmente es una muy mala idea. Puede que tengas uno aquí y otro allí para empezar y no es gran cosa, pero en poco tiempo tendrías una docena repartida por todo el lugar y te preguntas por qué tus páginas tardan 3 segundos en renderizarse. O cambia su esquema y secciones aparentemente no relacionadas del salto del sitio por razones desconocidas.

En mi opinión, un marco solo debe usarse si hace que el proceso de desarrollo sea más fácil para usted y no engorroso. No hay nada de malo en no usar un marco o construir uno propio, especialmente para proyectos pequeños.

Obviamente, aún deberá prestar atención a la estructura y los aspectos de seguridad, pero teniendo en cuenta que ha estado utilizando marcos durante muchos años, probablemente ya conozca esos aspectos al revés.

Para proyectos más grandes, estoy de acuerdo con los demás, lo que significa que usar un marco probablemente será la mejor opción a largo plazo.

Mis experiencias con los "frameworks" del lado del servidor han sido bastante desagradables, por ejemplo:

A) Jar file hell donde los marcos entran en conflicto entre sí o con el servidor de aplicaciones para versiones mutuamente incompatibles de cosas que no desea y no sabe nada y que no está en condiciones de dictar de todos modos, ya que evitará que se implemente en Múltiples servidores.

B) Explosión catastrófica de la creación de objetos más simple en miles de ejecuciones SQL innecesarias.

C) La extraña idea de que codificar 100 líneas de XML es de alguna manera más fácil o más confiable que codificar 2 líneas de Java.

D) La necesidad de escribir cientos de líneas de POJOS del lado del servidor completamente innecesarios para mapear en objetos del lado del cliente en otro, o en ocasiones en varios otros idiomas (C # JS, etc.)

E) No tengo idea de lo que realmente sucedió cuando obtienes un seguimiento de pila profunda de 30 niveles que ni siquiera incluye la línea de código que usaste para llamar al marco.

Sé un renegado, escribe tu propio marco ... no te arrepentirás mientras planees primero eliminar todas las cosas innecesarias que los demás te engañan haciéndole creer que necesitas. Entonces comprenderá todo, se enviará en Kb en lugar de Mb y probablemente "se ejecutará en cualquier lugar", que fue uno de los principios fundacionales de Java, ¿no?

Trate de pensar de esta manera "¿por qué necesito esto ... es solo para mantener el marco feliz?" .. Si no necesito eso, ¿qué más no necesito?

Hubo una presentación de los desarrolladores de Django, que ahora estoy teniendo problemas para encontrar, pero hablan sobre el "valle de la eficiencia" donde un marco te hace más productivo.

Suponiendo que no tiene conocimiento del marco cuando comienza un proyecto, su productividad inicialmente será muy baja: aprenderá la convención del marco en lugar del idioma del idioma (que con suerte ya lo sabrá).

Después de un corto período de tiempo, habrás captado las convenciones y aquí es donde realmente brillan los marcos: de repente, tu productividad está por las nubes y estás progresando y una velocidad increíble en el desarrollo.

Eventualmente, sin embargo, el proyecto tendrá un tamaño tal que el marco es más una restricción que una bendición, y se verá a sí mismo criticando el marco para intentar implementar algunas características.

En la presentación, mencionan que, por supuesto, si ya tiene conocimiento de las convenciones del marco, los proyectos de menor tamaño no tienen el obstáculo inicial para la eficiencia.

Por lo tanto, para proyectos pequeños (en mi experiencia, cualquier cosa menor a ~ 500 horas), su eficiencia con un marco será mayor, probablemente, que su eficiencia sin. Una vez que ingresa a un determinado umbral (entre 500 y 800 horas, IME), comienza a darse cuenta de que hay limitaciones en lo que el marco puede ofrecer.

Dicho esto, los marcos ofrecen un beneficio mucho mayor que solo la eficiencia: un marco como Symfony o Django o (supongo) Rails proporciona una convención que permite que un equipo se flexione dinámicamente y también permite que los clientes o propietarios de productos cambien su personal sin requerir el nuevo recurso para volver a aprender completamente un nuevo sistema: si están familiarizados con la convención de un marco, y se ha seguido esa convención, serán mucho más productivos inicialmente que de otra manera.

Un marco bien diseñado debería ser una ayuda para el programador, no un obstáculo. Si el marco que ha utilizado se interpone demasiado en su camino, le sugiero que busque un marco diferente. Cada uno tiene su propio estilo de codificación y sus propios pros y contras.

Habiendo dicho eso, el marco Zend parece ser muy popular en estos días, ¿y honestamente? Me cuesta ver por qué a veces. He tenido que trabajar con él en el pasado y no me ha gustado un poco su arquitectura. La clase Zend_Form está ridículamente diseñada, su sistema decorador tiene un uso absolutamente horrible, y los decoradores vinculan las formas a las vistas, rompiendo un concepto fundamental de POO que establece que los objetos deben estar acoplados libremente. También tiene una gran cantidad de código implementado como Singletones (que son malos por razones que están bien documentadas, así que no lo reiteraré) y el objeto Registro también contribuye a fomentar un estilo de codificación descuidado.

He oído que Zend Framework 2 (actualmente en versión beta) es un producto mucho mejor, pero el mal sabor que Zend 1 dejó en mi boca significa que no tengo ninguna prisa por probarlo.

Aún así, en este punto solo estoy despotricando. :) Hay muchos marcos, cada uno con sus pros y contras, sugiero evaluar algunos de ellos.

Lo que usted describe ha sido llamado "complejidad inducida por abstracción" en el pasado. El único documento sobre cómo administrarlo es: Administrar la complejidad inducida por abstracción por David Keppel. Keppel sugeriría que los marcos tienen un diseño que causa complejidad inducida por la abstracción.

Trabajar con un marco lo ayuda a acelerar su desarrollo al no reinventar la rueda . Framework también le proporciona las herramientas para ayudarlo a diseñar adecuadamente su aplicación (pero no le impide tomar malas decisiones de diseño, por ejemplo, acceder a la base de datos directamente desde la vista).

A veces, cuando necesita una funcionalidad personalizada, puede llevar más tiempo escribirla correctamente. Pero si constantemente está pirateando y encontrando soluciones, entonces está trabajando contra el marco o el marco no se adapta a sus necesidades.

En pocas palabras, a veces puede ser excesivo usar un gran marco para proyectos simples (por ejemplo, mostrar algunos campos de una base de datos). Para proyectos grandes o complejos, use un marco.

Existen múltiples lados para escribir su propio código en lugar de usar un Framework:

El tamaño, el conocimiento básico y la experiencia del equipo con el que está trabajando : si nunca usaron un marco o tienen una idea de cómo diseñar una aplicación, es mejor con un marco bien documentado con muchos ejemplos y ver que los acelera arriba.

El tamaño de la aplicación : nunca se sabe de antemano cómo se utilizará. Así que es mejor estar preparado para crecer y cambiar. ¿Puede su marco, que desea codificar en una noche, crecer con las necesidades de la administración? Cambie los tipos de campo en la base de datos y la implementación lleva un minuto o un día, ese es mi punto aquí.

La preparación : si usa un marco de trabajo, puede comenzar a diseñar la aplicación en lugar de codificar el núcleo de su aplicación, use uno donde la seguridad y la implementación sean partes importantes, eso es lo que lleva tanto tiempo. Cada vez.

Siempre discuto con "la administración" para usar Symfony2, ya que es un marco para el desarrollo web. La gerencia piensa que es demasiado grande, costará dinero y evitará a los programadores ya que la curva de aprendizaje es empinada.

Los marcos todavía se utilizarán para cualquier idioma en el moderno, especialmente para grandes proyectos. Cuanto más grande es un proyecto, más importante es un marco, para que sepa dónde está la lógica de todo y cada característica tiene un diseño similar. Facilita la modificación de un proyecto y el aprendizaje es más fácil cuando sabe dónde buscar todo el acceso a los datos, o todas las presentaciones, o dónde se administran las reglas de negocio.

Sin embargo, es necesario elegir un marco que se ajuste al proyecto, una solución empresarial requiere un marco capaz de la empresa. Este es el problema con el que te encontrarás al usar PHP. Muchos (la mayoría) de los marcos no están destinados a ser utilizados a gran escala, sin embargo, funcionan bien para sitios personales más pequeños. Para algo como el sistema de gestión escolar que mencionas, va a requerir un marco más sólido, y puede llevar algún tiempo encontrar un marco adecuado en PHP.