javascript - site - Modelo AngularJS cliente MVC?

instalar angularjs (7)

Hasta ahora, estaba usando principalmente la pila de tecnología Struts 2 , Spring , JQuery para crear aplicaciones web. El punto es que esa pila mencionada usa un patrón MVC lado del servidor. La función principal de los navegadores web se limitaba a un ciclo de solicitud / respuesta (+ validación del lado del cliente). La recuperación de datos, la lógica comercial, el cableado y la validación eran principalmente responsabilidades del lado del servidor.

Tengo algunas preguntas con respecto al marco de AngularJS que se inspiraron en las siguientes citas que he leído:

Del tutorial de AngularJS :

Para las aplicaciones angulares, recomendamos el uso del patrón de diseño Modelo-Vista-Controlador (MVC) para desacoplar el código y separar las preocupaciones.

Desde Wikipedia Model-view-controller :

Model-View-Controller (MVC) es una arquitectura que separa la representación de la información de la interacción del usuario con ella. El modelo consiste en datos de aplicación y reglas comerciales , y el controlador interviene en la entrada, convirtiéndola en comandos para el modelo o vista

AngularJS usa el patrón MVC lado del cliente. ¿Entonces supongo que no hay otra opción para incluir la lógica de validación también para el lado del cliente de alguna manera?

¿Cuál sería la mejor manera de escribir una aplicación AngularJS robusta? MVC en el lado del cliente y algún tipo de MC (modelo, controlador) en el lado del servidor?

¿Eso significa que ese MODELO y CONTROLADOR están duplicados de una manera (cliente / servidor)?

Sé que mi pregunta es extraña, pero creo que la razón es que estoy acostumbrado al patrón MVC del lado del servidor tradicional. Estoy seguro de que hay alguien que ya hizo la misma transición.

Creo que el término "lógica de negocios" es un nombre poco apropiado aquí. El "negocio" de una aplicación cliente es el negocio de manejar la interfaz de usuario. No van a ser cosas como las reglas de seguridad y la lógica de propiedad u otra propiedad intelectual sensible.

Entonces en Angular la división es (generalmente):

Controlador (controlador): para manipular los datos (alcance) detrás de su UI.
Directivas : para configurar el DOM para comunicarse con el controlador a través del alcance, y para manipular el DOM.
Plantillas (vista): para asignar directivas a elementos del DOM.
Alcance (modelo o modelo de vista): para transportar datos entre todas las piezas del sistema.
Servicios : bits de código inyectables y reutilizables. Por lo general, para dependencias como el manejo de Ajax, cookies u otras E / S.

Es realmente casi MVVM y no MVC.

En cuanto a su lógica o reglas de "negocios" ... cualquier cosa que requiera seguridad siempre debe estar asegurada a nivel de servidor.

Es importante entender que en algunas versiones del patrón MVC, tanto los datos como la lógica que manipulan los datos residen en la capa "modelo" (con la capa "controladora" haciendo nada más que vincular). En AngularJS, sin embargo, los datos ($ scope) solo residen en la capa "modelo", mientras que la lógica que manipula los datos ($ scope) reside en la capa "controlador".

Estoy de acuerdo con las respuestas aquí. Algunos más comentarios Cuando escribe una aplicación, primero debe concentrarse en el dominio del problema. Y cree un modelo de software de algunos negocios reales. Por ejemplo, si su dominio problemático es una compra, algunos de los requisitos que debe modelar podrían incluir:

La tarjeta de crédito debe ser válida.
Si paga con una tarjeta de crédito de la marca X, recibirá un 10% de descuento.
El carrito de compras debe contener al menos un artículo para realizar el pago
Los artículos deben tener stock antes de permitir a los usuarios agregarlos al carrito de la compra

La implementación de estos requisitos modelará su dominio problemático, esta es su lógica comercial.

Angular es un framework frontend y un juego de herramientas. Es una interfaz web . Si implementa esto en una interfaz web, perderá la oportunidad de reutilizar su modelo desde otra interfaz o interfaz, como una aplicación móvil o de escritorio. Entonces, idealmente, la implementación de su lógica de negocios debe estar desacoplada de cualquier marco de interfaz de usuario y desacoplada también de cualquier marco persistente. Luego, tendrá sus objetos de interfaz que se ocuparán de los problemas de la interfaz de usuario y se comunicarán con sus objetos de lógica de negocios. Puede ser un controlador Spring MVC y / o un controlador o servicio Angular.

Hay una aplicación de muestra que puede ver, que sigue los principios mencionados aquí.

Me encanta lo que dice @Roy TrueLove. Pero déjame decirte que esta es la mejor manera de usar angularjs. Por supuesto, debe aprender a hacer sus aplicaciones de esta manera, si desea obtener el mayor beneficio de angular. Rezo para estar allí algún día.

Mientras tanto, durante su aprendizaje, y durante su transición a utilizar angularjs por completo como su principal forma de hacer las cosas del lado del cliente, puede comenzar a usarlo para una pequeña misión aquí y allá, y gradualmente acostumbrarse a él y a su forma de pensando.

Animo a abrazarlo gradualmente y a ir despacio, pero seguramente, lo garantizo.

Angularjs está diseñado para servir a este enfoque, ya que puede funcionar en la tarea más pequeña y en la más grande. Por ejemplo, esta primera vez que usé angular fue solo para mostrar nombres mientras el usuario escribe los identificadores.

Mi enfoque es siempre el enfoque ascendente. A partir del diseño de la base de datos, con tablas construidas / relacionadas apropiadamente, procedimientos almacenados cuando sea necesario, luego agregue el marco de la entidad a la solución o use ADO.Net si EF no es una opción. Luego desarrolle la lógica de negocios y los modelos para obtener los datos dentro y fuera de la base de datos.

Con los Modelos establecidos, ahora podemos seguir dos rutas: Desarrollar MVC Controller y / o desarrollar el controlador WebAPI. Ambos controladores pueden tener acceso a los Modelos, solo es una cuestión de instanciar las clases e invocar los métodos.

Ahora tiene la opción de configurar MVC Views que están controladas por el controlador MVC, o un conjunto completamente separado de páginas HTML o SPA (aplicación de página única alojada en NodeJS).

Con el conjunto de páginas HTML completamente separado, necesitará usar controladores WebAPI, con los métodos Obtener, Publicar, Poner y Eliminar, y asegúrese de incluir un token de ida y vuelta para identificar a su cliente, y habilite CORS (para Cross Origin Request )

Con MVC Views, puede identificar a sus clientes utilizando los atributos del controlador y / o las sesiones y no debe preocuparse por CORS, e incluso puede hacer que sus Vistas sean muy escritas si es necesario. Desafortunadamente, si tienes un conjunto de desarrolladores de UI, tendrán que trabajar en la misma solución de MVC.

En ambos casos, puede usar AngularJS para transportar datos hacia y desde los controladores.

En mi humilde opinión, el concepto de controlador AngularJS no es lo mismo con el controlador C # MVC o C # WebAPI. El controlador AngularJS contiene toda la lógica de JavaScript así como las llamadas a los puntos finales a través de "ApiFactory", mientras que los controladores C # no son más que puntos finales en el lado del servidor que aceptan y responden a las solicitudes de UI.

No es en absoluto una pregunta extraña. He intentado vender Angular a muchos desarrolladores de Java y me preguntan esto. Yo mismo lo pregunté cuando estaba aprendiendo (todavía estoy aprendiendo, por cierto)

Si tomas una aplicación de Java ''convencional'' como la has descrito y la personalizas en Angularizar, primero debes tomar tu servidor y convertirlo en una API RESTful. Elimine los JSP, etc. Esta es realmente la parte más difícil, IMO, de escribir una aplicación angular: obtener la API REST correcta. La clave para mí para decidir qué lógica necesitaba ingresar al servidor era pensar en ella como una API pura y olvidar por el momento que tendría una interfaz .

Esa pregunta realmente me ayudó: si alguien intenta guardar un recurso dado y ese recurso no tiene datos válidos, no hay una interfaz que pueda decirles, están accediendo a la API directamente, por lo que la API debe rechazarla. Entonces, el back-end es responsable de la validación profunda. Esto se aplica también a su lógica comercial. Asuma que alguien está utilizando solo la API y quedará claro lo que su servidor debe hacer.

El servidor también necesita vender datos en formato (probablemente) json (utilizo Spring MVC + Jackson), por lo que es responsable de exponer el modelo a Angular y la comunicación con la base de datos.

Entonces, ¿cuál es el MVC entonces en el lado angular?

Modelo : los datos que provienen de la API REST. Si la API vende JSON, estos objetos ya serán objetos javascript de primera clase.
Ver : HTML y directivas cuando necesita manipular el DOM
Controlador : (y servicios personalizados que ha excluido de sus controladores ...)
- Consulta la API REST y coloca lo necesario para la Vista en $ scope
- Proporciona devoluciones de llamadas para que las directivas respondan a eventos que luego pueden requerir que se devuelvan las llamadas al servidor.
- Validación: generalmente a través de una devolución de llamada a una directiva. Es probable que se superponga a parte de la validación que ya ha puesto en el servidor , pero no desea que el usuario espere a que el servidor valide todo: el cliente debe saber algo sobre la validación para darle al usuario comentarios inmediatos.
- Lógica empresarial: prácticamente la misma historia que la validación.

Pero, ¿por qué la duplicación de lógica en el cliente y en el servidor? Sobre todo porque no estás escribiendo una aplicación, estás escribiendo dos cosas independientes:

una API REST que necesita ser robusta y utilizable sin una interfaz
una GUI que necesita dar retroalimentación inmediata a un usuario y no necesariamente esperar a un servidor.

Entonces, respuesta corta: obtenga la API REST correctamente olvidando que habrá una IU, y lo que entra en Angular será mucho más claro.

Parece que estoy teniendo esta pregunta también, ya que algunas organizaciones se vuelven locas por las nuevas tecnologías: "Quiero nube ... espere, quiero peso ligero", es difícil justificar si se merece para el cambio a un marco más ligero.

Desarrollo aplicaciones web usando Spring / JBoss seam / JSF y en framework MVC todo el tiempo. La mayoría de las veces, las secuencias de comandos de Java residen para las validaciones de la capa de presentación y las clases / entidades de acción principales y la lógica de negocios residen en el código de Java. Después de algunas prácticas básicas en Angular, comencé a entender lo que querían decir con MVC, ya que abstraían otro nivel en la capa de presentación, donde podemos tener nuestras propias vistas y controladores en la parte frontal. Para responder a su pregunta, al igual que los comentarios de todos, la mejor manera es colocarla en la capa de presentación.

En cuanto al punto de vista de seguridad, creo que las reglas comerciales pesadas o sensibles deberían residir en el lado del servidor ya que no queremos exponerlo al mundo. Si la lógica empresarial se desarrolla de manera deficiente, uno puede encontrar fácilmente la debilidad de nuestro código y explotarlo.

Aquí está mi pensamiento para el framework como Angular es como un pequeño cliente de compras / SOHO, y tienen pocas personas y son realmente eficientes y rápidos. Atienden bien a los clientes que enfrentan negocios y entregan / reciben productos de manera eficiente (REST, JSON). Tienen funciones y tareas designadas, pero algunos trabajadores realizan más que una tarea. La tienda también es vulnerable al ladrón o ladrones ya que generalmente no enfatizan la seguridad.

En cuanto a la estructura del lado del servidor como Spring / Struts 2, imagina una corporación moderna (CMM Level 5) con diferente nivel de administración y capaz de manejar negocios más grandes (trabajos por lotes, servicios web, bus empresarial). Ellos manejan al cliente, pero no directamente, a menudo pasan por intermediarios o incluso tiendas minoristas. En lo que respecta a la seguridad, una corporación es más sólida y, a menudo, los valores en la puerta de entrada o la información importante están protegidos en una caja fuerte (encriptación / inicio de sesión).