asp.net mvc - from - ¿Tiene sentido integrar backbone.js con ASPNET MVC?

mvc add new controller and view

Question

No soy un experto en estos componentes básicos, pero a primera vista me parece que:

• ASPNET MVC desea generar las vistas y administrar los modelos para una aplicación en el lado del servidor. Considera el navegador como un motor de presentación algo tonto, un consumidor de las vistas que le proporciona el servidor.

• backbone.js desea generar las vistas y administrar los modelos en el navegador. Considera el lado del servidor como un motor de persistencia basado en REST bastante tonto.

Esto parece una visión simplista. Estoy seguro de que no es toda la historia.

¿Cuáles son las oportunidades reales para integrar estas dos cosas? ¿Tiene sentido hacerlo? ¿O hay demasiada superposición entre ellos para que tenga sentido?

Me gustaría ver algún análisis o discusión sobre esto, si alguien puede referirme.

Answer 1

He usado asp.net mvc KO y bakcbone para diferentes proyectos y todo se reduce a la naturaleza del proyecto al final. La pila de servidores no se instalará una vez que sus flujos de trabajo comiencen a ser complejos o usted debe ofrecer UX a diferencia de las aplicaciones centradas en datos simples. Cuando su proyecto involucra un gran backbone, UX puede llevarlo allí. Lo malo es que no existen pautas centralizadas bien definidas para lo cual tendrá que atravesar infinidad de blogs para hacer las cosas. Para las aplicaciones convencionales, puede apegarse a KO. Por cierto, hay complementos que pueden simular KO para backbonejs. Me refiero a bacjbone.modelbinder. De nuevo necesitas integrarte por ti mismo. Cuz MS no molestará en absoluto.

Answer 2

Aunque no puedo hablar con backbone.js, puedo decirte que he usado knockout con gran efecto combinado con ASP.NET MVC. Cada aplicación ASP.NET que he visto hasta la fecha usa una mezcla de generación de vista del lado del cliente y del lado del servidor. Siempre habrá ocasiones en que sea más conveniente generar vistas en el servidor. Tomemos como ejemplo elementos de IU condicionales basados ​​en si un usuario está autenticado o si tienen un permiso específico. Es posible que no desee que un usuario conocedor de la web pueda explorar sus plantillas del lado del cliente y resolver todas las características que no están obteniendo. Claro que puedes evitar esto cargando asincrónicamente diferentes plantillas de cliente, bla, bla, o termina escribiendo código del lado del servidor para generar tus plantillas del lado del cliente ... Además, si SEO significa algo para ti, puedes besar las plantillas del lado del cliente ( por sí mismo) adiós.

Entonces, el punto óptimo, en mi opinión, es algo que hace las dos cosas bien. En mi experiencia, encontré ASP.NET MVC para destacar en ambos.

Por qué ASP.NET MVC es impresionante

• Diseños (páginas maestras)
• Razor (vistas de tipo seguro con bondad intellisense)
• ActionFilters (lugar increíble para aplicar convenciones como el registro, autenticación, etc.)
• Serialización JSON gratis - return Json(model)
• Encuadernación de modelos y validación
• IoC y MVC son mejores amigos (ganar)
• Autenticación + autorización
• Muchas otras cosas que no se me ocurren.

Al utilizar un marco del lado del cliente para la generación de vistas, realmente todo lo que se está perdiendo es Razor. Incluso puede aprovechar diseños en algún grado.

El enfoque que llevo al desarrollo con ASP.NET MVC es comenzar haciendo que la aplicación funcione en el lado del servidor. Esto te obliga a pensar en que quieres la estructura de tu URL, lo que merece un controlador, cuáles deberían ser tus rutas. También significa que obtendrá el beneficio de seguridad de tipo y autocompletar durante la primera iteración de vistas. Al final de este ejercicio, tiene una solución simple y compatible con los estándares (con suerte) que funciona en cualquier dispositivo conocido por el hombre, que Google no puede obtener suficiente.

Luego comencé a tomar un enfoque incremental para implementar segmentos de funcionalidad del lado del cliente. En el lado del cliente escribo un javascript para secuestrar una solicitud que deseo convertir en una solicitud AJAX, y manejo la respuesta usando una versión traducida de la vista Razor. En el lado del servidor, tomo un enfoque basado en la convención usando un filtro de acción. Este filtro de acción hace aproximadamente lo siguiente:

• ¿ActionResult es un ViewResult?
  • ¿Cuál es el tipo de Aceptar?
    • HTML - Devuelve un PartialViewResult del mismo nombre con el prefijo "_" dado el mismo modelo
    • JSON: devuelve un JsonResult dado el mismo modelo
• ¿El resultado de ActionResult es RedirectToRoute?
  • Devuelve EmptyResult (u opcionalmente puede devolver la URL en un JsonResult)

Con este enfoque, puede agregar funcionalidad AJAX sin cambiar una sola línea de código en los controladores. Un enfoque alternativo es seguir al Director de Thunderdome y tener un ActionInvoker responsable de ajustar el modelo en un tipo de resultado apropiado según el contexto de la solicitud. Sin embargo, no he resuelto cómo la navegación del lado del servidor (redirecciones) encaja con este enfoque.

El desperdicio al comenzar con una implementación del servidor es duplicar el código de generación de vistas (plantilla Razor + js). Dependiendo de la cantidad de su aplicación que desea implementar en el cliente, esto puede o no ser un problema. ¡Spark es la excepción a esto, ya que puedes generar plantillas de cliente para ti! La desventaja de Spark es que pierdes intellisense (hay un plugin para eso pero es una porquería) que no es una pérdida insignificante, además yo prefiero Razor (está hecho, no necesita ser configurado, y no va a desaparecer en ningún momento pronto).