TL; DR: debe usar un marco, pero solo después de saber qué arquitectura de la aplicación (o colección de arquitectura de la aplicación) usará.
Versión larga:
Usaría un marco, pero me aseguraría de que el marco no se convierta en una muleta.
- ¿Cuáles son las aplicaciones de las integraciones?
- Cómo ir para el desarrollo de sitios web de viajes con capacidades de motor de reservas para agencias de viajes de tamaño mediano
- Cómo determinar si crear una aplicación móvil o una aplicación web para empresas
- ¿Qué tan fácil es hacer nuevos amigos con personas cercanas a usted usando aplicaciones habilitadas para geo como Highlight?
- ¿En qué se diferencian los sitios web (en términos de tecnologías web utilizadas) de 2013 de 2003?
Al igual que los discapacitados pueden usar una muleta real para soportar su peso debido a su propia falta de fuerza, los desarrolladores pueden usar un marco como una muleta para soportar su propia falta de habilidad.
Un marco es solo una herramienta. Es comparable a un martillo en la construcción de edificios.
Un marco no debe ser la esencia de su aplicación más de lo que un martillo es la esencia de un edificio.
La “esencia” de un edificio es la arquitectura del edificio, y la “esencia” de una aplicación es la arquitectura de la aplicación.
No es aconsejable elegir su arquitectura en función de sus herramientas. Debe elegir sus herramientas en función de su arquitectura.
Una arquitectura de software impone restricciones en su diseño porque restringirse a las restricciones proporciona garantías.
El estudio de la arquitectura de software es el estudio de qué restricciones proporcionan ciertas garantías y cómo proporcionan esas garantías.
Por ejemplo, las personas usan las restricciones de la transferencia de estado representacional (REST) para proporcionar escalabilidad y mantenibilidad, y las personas usan una arquitectura de microservicio para proporcionar autonomía e interoperabilidad de los “servicios”. Sin embargo, esto es una pequeña simplificación.
Además, la mayoría de los sistemas usan una combinación de restricciones arquitectónicas. Por ejemplo, he visto a muchas personas combinar Arquitectura orientada a servicios, Arquitectura dirigida por eventos y Transferencia de estado representativa. Sin embargo, a pesar de tener la misma arquitectura, las implementarían utilizando diferentes herramientas (es decir, Spring para JAVA, Lavarel para PHP, Flask para Python).
