ASP.NET MVC con Knockout y API web: ¿tiene sentido?

asp.net-mvc knockout.js (5)

¿Tiene sentido usar los modelos de vista KnockoutJS en combinación con ASP.NET MVC3 o 4? Porque no es muy SECO, ¿verdad? Tengo que escribir modelos para EF, Viewmodels para MVC Views y Viewmodels para Knockout ... y pierdo mucha magia. Validaciones automáticas del lado del cliente, por ejemplo.

¿Tiene sentido utilizar MVC en absoluto si uno se atiene al patrón MVVM?

Con Knockout Mapping , puede generar automáticamente un modelo de vista KO desde su modelo de vista MVC.

Este es un patrón adecuado: sus modelos son entidades en bruto, sus datos. Sus puntos de vista son la interfaz de usuario. Y sus modelos de vista son sus modelos adaptados a esa vista específica.

Este es un tema antiguo, pero ahora en 2014 (desafortunadamente) todavía siento que esta pregunta tiene una gran relevancia.

Actualmente estoy trabajando en un proyecto que mezcla MVC4 con knockoutjs. Tuve algunas dificultades para encontrar qué parte se debe manejar en qué lado. Además, necesitábamos un tipo de arquitectura "SPA-ish", donde cada módulo tiene su propia página, pero dentro de ese módulo solo hay interacción AJAX. También enfrentó algunos escenarios de validación pesados y necesitaba proporcionar URL fáciles de usar (y SEO) dentro de cada módulo. Terminé con el siguiente concepto, que parece estar funcionando bien:

Funciones laterales básicas de MVC y .NET:

Manejo de autenticación y otras cosas de seguridad.
Implementación de la interfaz de la API web para las llamadas del lado del cliente (configuración de modelos de vista, recuperación y asignación de datos del dominio, etc.)
Generación de modelos de vista knockout desde mis modelos de vista C # (preexistentes) con plantillas T4 , que también incluyen extensiones de complemento de validación knockout de atributos de validación .NET. (Esto fue inspirado por este artículo ). Los modelos de vista generados son fácilmente extensibles, y la generación se puede ajustar con varios atributos personalizados o incorporados, como por ejemplo, DefaultValue, Browsable, DataType, DisplayFormat, etc. De esta manera el DRY no se viola (demasiado).
Proporcionar plantillas de vista parcial fuertemente tipadas , pero independientes de los datos para cada submódulo (cada modelo de vista). Debido a que los nombres de propiedades en los modelos de vista C # son los mismos que en los modelos KO, puedo beneficiarme de los ayudantes fuertemente tipados específicamente escritos para enlaces KO, etc.
Proporcionar la vista principal para cada módulo de manera similar al punto anterior.
Agrupación y minificación de todos los scripts y hojas de estilo.

Funciones básicas del lado del cliente:

Cargar el estado inicial de todos los modelos de vista encapsulados en una página de módulo, teniendo en cuenta la URL completa con una implementación sencilla del analizador de rutas.
Manejo de la historia con history.js
Enlace de datos, manejo de la interacción del usuario .
Publicación de partes relevantes de modelos de vista en el servidor y procesamiento de los datos devueltos (por lo general, actualiza algunos modelos de vista con él).

Espero que esto pueda ayudar a cualquier otra persona que se sienta perdida en el mundo de las tecnologías modernas. Por favor, si alguien tiene algún pensamiento sobre esto, siéntase libre de publicar cualquier pregunta o sugerencia en los comentarios.

Trabajo ahora en un proyecto que mezcla MVC3 y nocauts y tengo que decirles que es un desastre. En mi opinión, es absurdo forzar algunos patrones para estar al día con las tendencias.

Usamos el mapeo knockout para generar bien los modelos de vista KO.

Tenemos una capa de negocios en un proyecto separado que realiza CRUD, informes, almacenamiento en caché y algo de "lógica de negocios" adicional. No vamos a utilizar EF, o algo similar. Actualmente, hemos definido las clases c # como modelos MVC, y nuestros controladores llaman a la capa empresarial para construir los Modelos que se definen en el lugar habitual en nuestra aplicación MVC. Estos modelos C # se serializan como JSON para su uso en nuestras páginas.

Dado que todo lo que hacemos en el navegador está basado en c # / JSON usando knockout, no estamos utilizando los modelos MVC de la forma tradicional de MVC: todo se publica como JSON y se serializa en c #, por lo que no utilizamos el enlace, la validación, el modelo MVC. Estamos considerando mover estos modelos a nuestra capa de negocios para que puedan ser probados independientemente de la aplicación web.

Si nos quedamos con una aplicación MVC que tiene controladores y vistas, pero sin modelos, los controladores obtendrán los modelos que se definen en la capa empresarial. Estamos nerviosos por apartarnos de la estructura MVC normal, pero un cliente basado en KO / javascript es fundamentalmente diferente de un cliente basado en DOM sobre el que MVC se creó originalmente.

¿Suena esto como una forma viable de ir?

Esta puede ser una respuesta impopular, pero no uso ko.mapping para traducir mis POCOs de C # a modelos de vista JS. Dos razones, de verdad.

La primera es la falta de control. ko.mapping convertirá todo en un observable si lo dejas. Esto puede resultar en una gran cantidad de gastos generales para campos que simplemente no necesitan ser observables.

La segunda razón es sobre la extensibilidad. Claro, ko.mapping puede traducir mis POCOS de C # en objetos JS con propiedades observables. Eso está bien hasta el punto en que desee un método JS, que en algún momento, invariablemente lo hará.

En un proyecto anterior, en realidad estaba agregando métodos adicionales a los objetos ko.mapped mediante programación. En ese momento, me pregunté si ko.mapping realmente estaba creando más problemas de los que resuelve.

Tomo en cuenta sus preocupaciones DRY, pero de todos modos, tengo diferentes versiones enfocadas en el dominio de mis POCO. Por ejemplo, un objeto MyProject.Users.User servido por un UserController puede ser muy diferente de un MyProject.Articles.User . El usuario en el espacio de nombres de Usuarios puede contener muchas cosas relacionadas con la administración de usuarios. El objeto Usuario en el espacio de nombres de los Artículos podría ser una simple búsqueda para indicar el autor de un artículo. No veo este enfoque como una violación del principio DRY; más bien un medio de ver el mismo concepto de dos maneras diferentes.

Es un trabajo más directo, pero significa que tengo representaciones de Usuario específicas de problemas que no contaminan las implementaciones de los demás.

Y así es con los modelos de vista Javascript. No son C # POCOs. Son una toma específica de un concepto adaptado a un propósito específico; manteniendo y operando en los datos del lado del cliente. Si bien ko.mapping inicialmente le dará lo que parece ser un aumento de la productividad, creo que es mejor crear modelos de vista específicos diseñados específicamente para el cliente.

por cierto, uso exactamente la misma estrategia MVC3 / KnockoutJS que tú.