asp.net mvc - tutorial - SOA vs MVC-cuándo usar
razor pages vs mvc (2)
He leído this tema pero aún no tengo una imagen completa y realmente agradecería su respuesta a la siguiente pregunta:
- para qué tipo de aplicación se debe utilizar el enfoque SOA (obtener JSON desde el lado del servidor y generar html en el lado del cliente utilizando el marco de javascript, como knockout js, angular js y así sucesivamente), y ASP.net MVC en el lado del servidor, como alternativa Enfoque de arquitectura (generar páginas totalmente en el lado del servidor y devolver vistas como resultado).
Por ejemplo, para el último SPA con lógica del lado del cliente wcf services + knockout js (MVVM del lado del cliente) se obtuvo un gran resultado. Pero qué enfoque será más adecuado para la aplicación CRUD (por ejemplo, varias tablas para agregar, actualizar datos con diferentes roles de usuario en uso).
Las arquitecturas MV * (MVC, MVP, MVVM, etc.) del lado del cliente y las arquitecturas MV * del lado del servidor son las mismas en lo que respecta a la parte SOA de su arquitectura.
El modelo es donde se comunica con los servicios y obtiene datos de los diversos servicios. La elección entre el lado del cliente * y el lado del servidor es ortogonal.
SOA es mucho más que enviar JSON a un cliente web.
Imagine que tiene un negocio con un sistema de software basado en bases de datos para cosas como ventas, inventario, informes, etc. La mayoría de los sistemas empiezan siendo pequeños, con solo un cliente o una aplicación web que habla directamente con la base de datos ... y está bien.
Sin embargo, a medida que el sistema crece, hay algunas cosas que no encajan bien dentro de este modelo: procesos por lotes de larga ejecución que bloquean la aplicación o la página web, trabajos programados que involucran más que solo el servidor de bases de datos, procesos que involucran datos que viven en fuentes externas, o informes complejos que atascan su base de datos mientras se ejecutan. En este punto, querrá pensar en agregar un servidor de aplicaciones para manejar algunas de estas tareas. Un servidor de aplicaciones puede quitar parte de esa carga de trabajo de sus clientes. También puede quitar ciertas cargas de lo que es probable que en este momento sea una base de datos con exceso de trabajo, de modo que el servidor de aplicaciones solicite o transfiera datos en bruto hacia y desde la base de datos, y su aplicación solicite / envíe datos transformados hacia y desde la aplicación servidor.
A medida que el sistema crece aún más, también descubrirá que diferentes partes del sistema tienen efectos secundarios inesperados en otras partes a medida que mantiene las cosas. Incluso las mejoras simples se vuelven cada vez más complicadas de completar. El desarrollo se ralentiza y el número de fallos aumenta. El servidor de aplicaciones ahora se convierte en un gran lugar para centralizar los esfuerzos de diseño sobre cómo asegurarse de que un cambio en un área tenga las consecuencias esperadas (y solo las consecuencias esperadas) en cualquier otra parte.
Al principio, lo que realmente es una SOA, entonces, es tomar ese servidor de aplicaciones (lo que podría suceder al usar json sobre http, pero también podría ofrecer una interfaz completamente diferente o incluso traducir automáticamente entre varias tecnologías de transporte de datos) y aplicar todas las reglas, no solo algunos, el acceso a la base de datos pasa por este servidor de aplicaciones: la capa de servicio.
Una vez que se impone este acceso, y nada más se comunica directamente con la base de datos (al menos, nada que no se explique específicamente), la capa también se convierte en un gran lugar para comenzar a aplicar las reglas empresariales y la lógica del sistema. Aquí le permite escribir código de estilo de aplicación tradicional que es más fácil de usar con control de código fuente que sql y se compartirá automáticamente entre cualquier aplicación que use el sistema. El código vive en el mismo lugar y, por lo tanto, es más fácil modelar los cambios y sus efectos a través del sistema. Como beneficio adicional, esta capa suele ser muy fácil de escalar a múltiples servidores redundantes, por lo que puede convertirse en una forma de mejorar y administrar el rendimiento y la confiabilidad de una aplicación grande. En el back-end, también puede mejorar el rendimiento al simplificar y centralizar los esfuerzos para usar las herramientas de almacenamiento en caché de la base de datos como redis, lo que facilita la participación de un DBA dedicado en el ajuste del rendimiento y lo ayuda a centralizar el acceso a los datos que viven en múltiples lugares.
En este punto, su sitio web de MVC es solo una aplicación más que se conecta al servidor de aplicaciones en su sistema SOA. También puede tener una aplicación de cliente-servidor heredada instalada en algunos escritorios, o su aplicación MVC puede ser pública, mientras que los representantes reales de ventas y soporte usan algo completamente diferente, la facturación usa una aplicación diferente, y el cumplimiento de pedidos o compras tienen otra interfaz. ... pero todos hablan a la misma capa de servicio. Una ventaja adicional aquí es que esta capa de servicio facilita la obtención de datos de múltiples fuentes, por lo que si su sistema de fabricación necesita información de disponibilidad de material de un sistema externo, la capa de servicio puede saber cómo encontrarlo y el código de front-end no lo hace. No hay que saber que estos datos provienen de algún lugar especial.
El punto de todo esto es que no es un caso de ninguno de los dos o aquí. Si tiene una SOA, puede usar MVC en un nivel del sistema, y la interfaz proporcionada por la capa de servicio de la SOA determinará qué aspecto tiene su modelo de MVC y cómo se comporta el controlador. Si no tiene una SOA, MVC simplemente funciona bien en la construcción de toda la pila, desde la base de datos hasta la presentación, y de hecho funciona de tal manera que el modelo se convierte en un microcosmos para una capa de servicio más grande.
La pregunta, entonces, de cuándo usar JSON y cuándo usar ASP.Net MVC toma una nueva forma. ASP.Net MVC puede ser parte de una arquitectura SOA, y los marcos de servicios que ofrecen datos JSON a menudo se implementan utilizando bibliotecas MVC del lado del cliente. Realmente desea saber cuándo es más apropiado hacer más en el lado del cliente y más en el lado del servidor. Honestamente, creo que esto es principalmente una preferencia personal, pero hay concesiones que debe tener en cuenta.
Trabajar más del lado del cliente puede ser excelente para el rendimiento y la escalabilidad, ya que distribuye la carga de trabajo de su aplicación entre todos los sistemas informáticos de sus usuarios, y puede reducir la latencia introducida al realizar viajes de ida y vuelta a un servidor web o servidor de aplicaciones.
Por otro lado, hacer más trabajo en el lado del servidor es bueno para evitar la latencia en la transferencia de conjuntos de datos más grandes a través de enlaces de Internet públicos más lentos, puede hacer que sea más fácil cumplir con los requisitos de cumplimiento de requisitos como los mandatos de accesibilidad de la Ley de Discapacidades de EE. UU. los problemas con los navegadores accesibles o el envío de datos a los sistemas cliente pueden constituir un riesgo de privacidad o seguridad, y pueden facilitar el desarrollo, la implementación y el mantenimiento de un nuevo código cuando la mayor parte del procesamiento ocurre dentro de la misma capa.