asp.net mvc - ¿Hay alguna razón por la que usaría Knockout MVC en lugar de Knockout JS?

asp.net-mvc asp.net-mvc-3 (12)

Otro usuario sugirió Knockout MVC para manejar algunos problemas de publicación de AJAX. Leí un poco sobre él y veo que es un envoltorio alrededor de Knockout JS . Entonces me pregunto ¿cuáles son las diferencias reales entre los dos? ¿Debería molestarme con Knockout JS ya que existe Knockout MVC ? ¿Cuándo usaría uno sobre el otro?

Aún tiene el rendimiento si no está utilizando funciones generadas por komvc. Como dijo Nigel, la generación de la página inicial todavía tendría que ser generada por el servidor. Siempre puede agregar scripts de usuario y crear funciones en el lado del cliente que no necesiten volver al servidor. Es una herramienta que le da al desarrollador un poco de productividad. La comparación con los formularios web sobre el rendimiento es ciertamente exagerada. Gente, esa es una herramienta que seguro lo ayuda a cumplir su fecha límite.

Agregaré mis 2 centavos a favor de knockoutjs, aunque escribir es algo complicado en comparación con MVC nocaut, el beneficio que obtienes es enorme en lo que respecta a la reutilización. El código del cliente también puede funcionar armoniosamente con otras tecnologías.

Dejando a un lado la perspectiva de la seguridad, personalmente creo que knockout js es una forma de complicar asp.net MVC y debe usarse tal cual (knockout js) con aplicaciones RESTful puras como asp.net webapi.

En el patrón .Net MVC, visualice claramente el modelo que marca en cada vista / vista parcial con la etiqueta "@model yourmodel", que puede ayudar al desarrollador a comprender qué hará en esta vista.

Al usar el patrón MVVM de knockout.js, posiblemente no vea ningún modelo de vista .Net, excepto etiquetas como "enlace de datos" en las vistas. Esto haría que la vista y el controlador se desacoplaran y resultara difícil rastrear la lógica especialmente para un nuevo desarrollador en un equipo.

Creo que el knockoutMVC puede resolver esas dificultades y guardar una gran cantidad de códigos javascript que dificultarán el mantenimiento y la comprensión del sistema.

Dado que knockoutMVC hace que el diseño aún se quede en aplicar el modelo de vista del lado del servidor que es fácil de rastrear y mantener ya que es el código C #.

Para un proyecto empresarial, el gerente siempre debe enfocarse en su fácil desarrollo, fácil mantenimiento, fácil actualización y fácil comprensión, y entregado rápidamente para ganar dinero.

Sacrificar un poco el rendimiento pero hacerlo simple, la consistencia en el lado del cliente y en el servidor debería ser un punto clave. Javascript es un gran problema de mantenimiento.

¿Es realmente una cuestión devolver todo el modelo de vista al servidor? Si lo hace, podemos dividir un modelo grande en varios modelos pequeños.

Encuentro que la respuesta de Tyrsius es un poco negativa. Knockout MVC todavía está en desarrollo temprano, pero por lo que puedo ver tiene algunas ventajas y es menos pesado que las Webforms, por ejemplo. Las dependencias de Visiblity obtienen manejos completamente en el cliente, solo cuando se utilizan funciones se realiza una llamada al servidor. Cuando se trabaja con estructuras de datos complejas, a veces se requiere pasar por el servidor de todos modos, entonces Knockout MVC podría ser una buena forma de ahorrar al escribir mucho Ajax.

Es cierto que siempre envía todo el modelo de un lado a otro, lo que le da un poco de sobrecarga en lugar de construirlo usted mismo. Pero no lo escribiría por completo. Especialmente cuando se maneja adecuadamente el lado del cliente para validaciones complejas en el futuro.

Knockout MVC es una poderosa extensión para ASP .NET MVC que le permite implementar la funcionalidad del cliente del sitio web directamente en su proyecto .NET utilizando el desarrollador friendly fluentAPIs sin Javascript y eliminando una gran cantidad de código duplicado y repetitivo.
knockout MVC es lo mismo que codificar ASP .NET MVC Navaja y obtienes la funcionalidad del cliente sin ningún tipo de molestia adicional.
No tendrá que codificar un modelo de vista y líneas de código de enlace.
He estado usando koMVC en la mayoría de mis sitios web y la reducción del tiempo de desarrollo, el mantenimiento fácil y la curva de aprendizaje mínima son una gran recompensa.
Sugiero que revises su sitio web y pruebes algunos ejemplos en vivo. http://knockoutmvc.com
No tardará mucho en que te enamores de él.

La belleza de Knockout.js es que puede obtener su aplicación sirviendo simplemente pasando JSON hacia adelante y hacia atrás desde el servidor sin tener que presionar una vista completa que el servidor tuvo que dividir para generar HTML.

Parece muy contra-intuitivo volver a ponerlo en el servidor. Si eso te interesa, es mejor que utilices la sintaxis de la navaja de afeitar para realizar tu encuadernación en primer lugar.

Mi sugerencia sería utilizar knockout.js para hacer su enlace, de modo que la vinculación tenga lugar en el cliente y no en el servidor si este es el objetivo que está buscando. Si desea que su vista esté enlazada a datos en el servidor, use una afeitadora.

Más, knockout.js seguro es muy bueno en la visualización de datos del lado del cliente / eliminar / insertar / actualizar, y el cálculo de los datos del lado del cliente. Si una lógica comercial real es tan simple como eso, debemos aplicar knockout.js directamente.

La verdad es que la lógica empresarial no siempre es así de simple. Por ejemplo, cuando el cliente inserta un nuevo registro en la vista, el sistema posiblemente necesite verificar la autenticación del Usuario, establecer valores predeterminados para el nuevo objeto creado en base a alguna lógica comercial o fórmula, etc. Todo esto, de todos modos, debe ir al servidor y verificar lógica basada en datos de la base de datos.

El desarrollador puede traducir toda la lógica de negocios requerida en métodos de script java dentro del modelo de vista de knockout.js. Pero de esta manera, el diseño viola la regla de manejar la lógica de negocios centralizada.

El mantenimiento se convertirá en una pesadilla para tal diseño.

Resumen, qué opción de marco realmente depende de los requisitos del negocio. En algún momento, el rendimiento no es la primera consideración.

MVC es un patrón de arquitectura que se separa en tres componentes, Modelo, Vista y Controlador.

KnockoutJS funciona mejor con la arquitectura MVC porque el enlace de datos del marco requiere el uso de un controlador. Hay frameworks como AngularJS que se enfoca más en el front-end y, por lo tanto, funcionan mejor con el patrón de arquitectura MVVM (modelo, vista, modelo de vista). Sus características de enlace de datos tampoco requieren el uso de un controlador que reduzca el alcance del enlace.

Me encontré con esta pregunta que tiene algunas respuestas bastante negativas. Voy a agregar rápidamente mi valor de dos centavos.

Recién comencé a usar KnockoutJS. Como estoy creando aplicaciones ASP.NET MVC, me pareció lógico utilizar algo como Knockout MVC. En su mayor parte, parece una gran idea. No quiero perder el tiempo escribiendo javascript y  comentarios a través de mis páginas si puedo hacer lo mismo usando la funcionalidad .Net que conozco y amo.

Habiendo dicho eso ... sí, hay limitaciones para KMVC en este momento. Volver a enviar todo el modelo al servidor es muy importante. Entonces lo que hice fue comenzar mi propio tenedor de knockout-mvc. Los cambios han sido necesariamente apresurados en este momento. Pero ahora tengo la capacidad de:

crear subcontextos (con modelos o componentes completamente diferentes del modelo de vista)
pasar partes seleccionadas del modelo de nuevo cuando se llama al servidor
esperar un modelo diferente de una llamada que lo que se envió
eventos de fuego alrededor de las llamadas ajax
admitir más tipos de entrada html5
pasar tokens contra falsificación al servidor a través de encabezados (para llamadas ajax)
probablemente más he olvidado

Espero volver pronto y realmente limpiar lo que he hecho. Con suerte, el autor incluirá estos cambios en su código. Si no, supongo que mantendré mi propio tenedor en marcha. De cualquier manera, hay luz al final del túnel. KMVC podría necesitar un trabajo tal como está, pero creo que el concepto definitivamente valió la pena.

Definitivamente pienso

Si Knockout MVC muere mañana, la web será un lugar mejor.

fue un poco duro

Editar:

Estaba viendo los comentarios y volví a ver cuál era la pregunta original. Una vez hecho eso, creo que se debe agregar un poco más a mi respuesta:

En primer lugar, la pregunta original era: ¿Hay alguna razón por la que usaría Knockout MVC en lugar de Knockout JS? Para responder / aclarar (tal vez estoy siendo exigente) que: Knockout MVC es un marco diseñado para facilitar la integración de KnockoutJS con su aplicación ASP.NET MVC. Lo hace principalmente mediante el uso de construcciones conocidas y fuertemente tipadas para generar etiquetas KnockoutJS. No es un reemplazo para KnockoutJS. Por supuesto, use KnockoutJS. La pregunta es si también usar Knockout MVC.

Habiendo dicho eso, la elección sigue siendo la tuya como desarrollador para elegir cuándo usar varios aspectos de todas las herramientas disponibles para ti. Si desea manejar un cierto aspecto de la funcionalidad realizando una solicitud completa de vuelta al servidor, entonces hágalo. Si desea realizar una solicitud ajax para recuperar / actualizar datos, entonces hágalo. Si desea realizar una funcionalidad puramente del lado del cliente, entonces hágalo.

El uso de Knockout MVC no evita que utilices KnockoutJS para que esté lleno. El uso de Knockout MVC no le impide escribir javascript adicional para manejar la mayor funcionalidad del lado del cliente que desee. El hecho de que Knockout MVC le proporcione un atajo para generar ajax devoluciones de llamada al servidor no significa que tenga que usarlos. Aunque, si su aplicación persiste alguna vez en los datos, tendrá que llamar a casa en algún momento.

Existen razones para construir un backend de aplicación usando ASP.NET MVC en comparación con solo usar Apache para servir archivos estáticos de HTML y script. Knockout MVC le permite continuar aprovechando esos mismos beneficios para ayudar con la integración de KnockoutJS.

Me he encontrado con esta publicación después de buscar un poco sobre knockout mvc. Aunque estoy de acuerdo con el desperdicio del ancho de banda de la red, me siento bastante seducido por esa línea de código:

@{ var ko = Html.CreateKnockoutContext(); }

Esta es una forma ordenada y limpia para generar el modelo de vista knockout. ¿Alguien ha utilizado MVC knockout solo para esa función y sin mover toda la lógica al lado del servidor?

También puedo ver muchos buenos casos de uso con la biblioteca Knockout MVC. Difícilmente podría integrar KnockoutJS en nuestra aplicación web MVC, exactamente por razones que fueron señaladas, por ejemplo, @ChinaHelloWorld. Aquí hay algunos casos en los que lo encuentro extremadamente útil.

Enlaces fuertemente tipados

Me gustaron los lindos métodos de ayudantes de HTML, que se volvieron completamente inútiles y complicados a la hora de configurar KnockoutJS. Lo mejor que podía hacer era conectar manualmente mis atributos de enlace con el parámetro extra de los métodos de ayuda, pero tenía que usar cadenas mágicas allí de nuevo. Me gustan los ayudantes provistos por Knockout MVC para crear entradas y otros elementos con encuadernaciones basadas en expresión C-type fuertemente tipadas. Sin embargo, aquí me gustaría mencionar que echo de menos el atributo de nombre de los campos generados, así que tuve que modificarlo un poco.

Sintaxis de enlace fuertemente tipada (tipo de)

Cuando se usan enlaces de cadenas puras, siempre hay una buena posibilidad de errores de ortografía, o no saber exactamente el formato correcto del enlace que desea aplicar. Con la fluida API de Knockout MVC y VS IntelliSense, es realmente fácil aplicar los enlaces correctos.

(Casi) Conversión automática desde propiedades de C # calculadas a enlaces computados

Solo con la aplicación del pequeño atributo [Computado], Knockout MVC puede generar la expresión de enlace correspondiente en la sintaxis correcta de KnockoutJS. Este también es muy útil, creo.

Sin duplicación de código de viewmodel

De la manera clásica, necesitaba tener la clase viewmodel en código C #, y luego (casi) el mismo código de modelo de vista en JS (con observables). Bueno, ESO fue frustrante para mí, y me sentí extremadamente feliz cuando vi la técnica utilizada en Knockout MVC. Sin embargo, tuve que modificarlo un poco para poder usarlo con modelos de vista realmente complejos (modelos de vista anidados, colecciones, etc.) y para poder ampliar los modelos de vista Knockout mapeados con, por ejemplo, cualquier método JS personalizado necesario u observable calculado .

Así que aquí hay al menos cuatro puntos muy buenos. Y sobre los viajes de ida y vuelta del modelo de vista: nadie dijo que cualquiera de nosotros necesita usar el mecanismo de procesamiento del lado del servidor de Knockout MVC. Yo tampoco usaría eso, solo si hay alguna lógica comercial compleja que realmente deba procesarse en el servidor. Pero en la mayoría de los casos, Knockout MVC es solo para simplificar el proceso de enlace y configuración de MVC Views y KnockoutJS. Así que no entiendo muy bien las malas opiniones anteriores. Creo que quienes escribieron estas opiniones no se tomaron el esfuerzo de aprender al menos los conceptos básicos de Knockout MVC. Definitivamente NO deberías usar Knockout MVC en lugar de KnockoutJS, pero además de KnockoutJS . Entender Javascript y al menos los conceptos básicos de KnockoutJS sigue siendo obligatorio en cualquier caso.

Deseo que el autor continúe con el desarrollo de Knockout MVC, porque además de estos buenos puntos, hay algunas características y refinamiento que lo harían aún más poderoso.

Knockout MVC es el hijo bastardo de WebForms . Enlaza todos los métodos de viewmodel a través de acciones de controlador, lo que significa que todo lo que sucede tiene que rebotar en el servidor y volver. No puedo entender por qué alguien tomaría un framework como knockout, que pretende ser CLIENT SIDE MVVM, y lo forzará a llamar al servidor para cada función.

Además, la realización de esos métodos en el servidor significa que todo el modelo de vista debe pasarse al servidor y volver al cliente para cada llamada de función. Esto es increíblemente derrochador.

Usar Knockout MVC significa sacrificar todos los beneficios de rendimiento del código del lado del cliente por el beneficio de no tener que escribir javascript. El mismo intercambio de WebForms hecho. No es bueno. Es un antipattern

Si Knockout MVC muere mañana, la web será un lugar mejor.