MVC es una forma saludable de dividir un flujo de usuarios transaccionales (el comportamiento A modifica el estado B que conduce a la presentación C), pero tomado como una religión es difícil de manejar. Es una metodología para ayudar a resolver un problema, no todos los problemas son MVC. He escuchado argumentos para las partes “gruesas” y “delgadas” de MVC y para mí eso significa que potencialmente ha perdido de vista su problema actual y está tratando de justificar el código que funciona en un patrón venerable. Los méritos más fuertes de MVC lo ayudan a identificar de manera clara la propiedad de las capas como parte de la interacción del usuario con su software. Como parte de ese proceso, puede marcar las tecnologías utilizadas, los formatos de entrega esperados, etc. También puede ayudarlo a comprender plataformas alienígenas de una manera más rápida. No mucha documentación técnica le dirá que esta es la “M”, esta es la “V”, etc. de su organización, pero con el patrón en mente puede ayudar a que las bombillas mentales parpadeen más rápido.
Bien, todo lo dicho, como mencionó el Sr. White, escuchó mucho más sobre las pilas de tecnología de redes de 3 niveles (o incluso de 7 niveles) cuando las empresas basadas en Internet comenzaban a explotar. Los servicios web transaccionales han sido una criatura que evoluciona lentamente, simplemente porque HTTP está en su núcleo sin estado. MVC, que era un patrón mucho más popular en las aplicaciones de escritorio nativas, se habló más una vez que otras tecnologías como las cookies del navegador, el seguimiento de la sesión del lado del servidor, etc., superaron (principalmente) la apatridia de HTTP. De manera similar, a medida que el seguimiento del estado del usuario evolucionaba, también evolucionaban tecnologías de plantillas más sofisticadas para evitar las limitaciones de componer HTML directamente en su código; en cierto modo, las plantillas fueron el nacimiento de la “V” en MVC basado en la web. La maduración de JavaScript y AJAX (devoluciones de llamada asíncronas) aumentaron la necesidad de formalizar las necesidades entre los servicios. Finalmente, a medida que la sofisticación creció en torno a dónde se mantenía y se accedía al estado de los datos más allá del sistema de archivos y al acceso directo a las bases de datos, surgieron formas optimizadas de tratar los datos de una manera relacional a una basada en la clase a través de ORM. Las bases de datos relacionales se tropezaron en el camino, el almacenamiento en caché como surgió memcached u otros sistemas de datos secundarios basados en búsquedas locales como Lucene, y de repente la fuente de verdad se volvió mucho más complicada que una consulta SQL en código. En resumen, como complejidad para hacer que el navegador sea tan útil como una aplicación de escritorio, impulsó la estructura subyacente de la tecnología a evolucionar hacia MVC.
TL; DR: MVC surgió como una forma de crear software de servicios web porque es muy adecuado para la interacción del usuario y no simplemente sirve archivos HTML sin estado.
- ¿Cómo se usa la computación en la nube en el trabajo? ¿Qué problemas puede resolver la computación en la nube? ¿Qué factores le impiden realizar más operaciones en la nube? En su respuesta, ¿podría incluir su posición?
- Cómo calcular el costo de adquisición del cliente (CAC) y el valor de por vida (LTV) de un cliente en un modelo SaaS
- ¿Debería ofrecer una indemnización mutua al vender un producto SaaS?
- ¿Cuáles son los mejores canales de comercialización para las empresas SaaS?
- ¿Qué es una buena pila SaaS para ejecutar un negocio de inicio?
