Existe-t-il une raison pour laquelle je voudrais utiliser Knockout MVC au lieu de Knockout JS?

Question

Un autre utilisateur a suggéré de knock-out MVC pour gérer certains AJAX problèmes de publication. J'ai lu un peu sur elle et je vois que c'est un wrapper autour de knock-out JS. Donc, je me demande quelles sont les réelles différences entre les deux? Dois-je la peine avec knock-out JS depuis knock-out MVC existe? Quand devrais-je utiliser l'un plutôt que l'autre?

Answer 1

Knock-out MVC est l'enfant bâtard de WebForms. Il achemine tous les viewmodel méthodes à travers les actions du contrôleur, le sens de tout ce qui arrive a la faire rebondir sur le serveur et à l'arrière. Je ne comprends pas pourquoi quelqu'un voudrait prendre un framework comme knock-out, qui est destiné à être CÔTÉ CLIENT MVVM, et de le forcer à appeler le serveur pour chaque fonction.

En outre, l'exécution de ces méthodes sur le serveur signifie que l' ensemble du viewmodel doit être transmis au serveur et au client, pour chaque appel de fonction. C'est incroyablement inutile.

À l'aide de knock-out MVC signifie sacrifier tous les avantages de performance de code côté client pour l'avantage de ne pas avoir à écrire du code javascript. Le même trade-off WebForms fait. Il n'est pas bon. C'est un antipattern.

Si knock-out MVC meurt demain, le web sera un meilleur endroit.

Answer 2

J'ai juste couru à travers cette question, qui possède un bon nombre de réponses négatives. Je vais vite y ajouter mon grain de sel.

J'ai tout juste commencé à utiliser KnockoutJS. Depuis que je suis en train de construire ASP.NET MVC apps, il me semblait logique d'utiliser quelque chose comme knock-out MVC. Pour la plupart, il semble comme une grande idée. Je ne veux pas passer du temps à écrire du javascript et de l' <!-- ko --> commentaires par le biais de mes pages si je peux faire la même utilisation .Net fonctionnalité que je connais et j'adore.

Après avoir dit que... oui, il y a des limites à KMVC pour le moment. L'envoi de l'ensemble du modèle vers le serveur en est un gros. Donc ce que j'ai fait est de commencer mon propre fourchette de knock-out de la mvc. Les changements ont été nécessairement se précipita sur le moment. Mais j'ai maintenant la possibilité de:

• créer des sous-contextes totalement différents modèles ou des composants de la vue modèle)
• passer des parties sélectionnées du modèle lors de l'appel du serveur
• s'attendre à un modèle différent de retour d'un appel de ce qui a été envoyé
• le feu des événements autour des appels ajax
• support de plusieurs types d'entrée html5
• passage anti contrefaçon des jetons pour le serveur via les en-têtes (pour les appels ajax)
• probablement plus que j'ai oublié

Je suis l'espoir de revenir bientôt et très propre jusqu'à ce que j'ai fait. J'espère que l'auteur va inclure ces changements dans son code. Si non, je suppose que je vais garder mon propre fourchette allant. De toute façon, il y a de la lumière au bout du tunnel. KMVC pourriez avoir besoin de travailler comme il est, mais je pense que le concept a été certainement la peine de le faire.

Je pense vraiment qu'

Si knock-out MVC meurt demain, le web sera un meilleur endroit.

a été un peu dur.

Edit:

J'ai été en regardant les commentaires et regardé de nouveau à ce que la question initiale a été. Ayant fait cela, je pense qu'un peu plus devrait être ajoutée à ma réponse:

D'abord, la question était Est-il une raison pour laquelle je voudrais utiliser knock-out MVC au lieu de knock-out JS? Pour répondre/préciser (peut-être que je vais être pointilleux): knock-out MVC est un cadre destiné à faciliter l'intégration de KnockoutJS avec votre ASP.NET MVC app. Elle le fait principalement à l'aide de familier, fortement typé construit pour générer KnockoutJS balises. Il n'est pas un remplacement pour KnockoutJS. Par tous les moyens l'utilisation KnockoutJS. La question est vraiment de savoir si l'utilisation knock-out MVC ainsi.

Cela dit, le choix est toujours la vôtre en tant que développeur de choisir quand utiliser divers aspects de tous les outils disponibles pour vous. Si vous souhaitez gérer un certain aspect de la fonctionnalité par l'exécution d'une demande complète, de retour sur le serveur, puis le faire. Si vous souhaitez effectuer une requête ajax pour récupérer/mise à jour des données, puis le faire. Si vous souhaitez effectuer des fonctionnalités purement côté client, puis le faire.

À l'aide de knock-out MVC n'a pas à vous empêcher d'utiliser KnockoutJS à son maximum. À l'aide de knock-out MVC n'est pas de vous empêcher de vous écrire javascript supplémentaire pour gérer autant de client-côté fonctionnalités que vous souhaitez. Tout simplement parce que knock-out MVC vous fournit un raccourci pour générer des rappels ajax vers le serveur ne veut pas dire que vous avez à les utiliser. Bien que, si vous avez déjà persiste données, qu'elle va avoir à appeler à la maison à un certain point.

Il y a des raisons pour la construction d'une application backend à l'aide de ASP.NET MVC, comparée à l'aide d'Apache pour servir HTML statique et les fichiers de script. Knock-out MVC permet de continuer à profiter de ces avantages pour aider à KnockoutJS intégration.

Answer 3

Je trouve Tyrsius réponse un peu trop négatif. Knock-out MVC est encore au début de leur développement, mais de ce que je peux voir qu'il a certains avantages et est moins serveur lourd que Webforms par exemple. Visiblity dépendances obtenir poignées entièrement sur le client, uniquement lors de l'utilisation de fonctions un appel est fait pour le serveur. Lorsque l'on travaille avec des structures de données complexes, il est parfois nécessaire de passer par le serveur de toute façon, alors knock-out MVC peut être un bon moyen d'économiser sur l'écriture de beaucoup de Ajax-manutention vous-même.

Il est vrai qu'il envoie toujours l'ensemble du modèle d'avant en arrière, ce qui donne une surcharge, plutôt que de construire vous-même. Mais je ne dirais pas de l'écrire entièrement. Surtout quand il fait du bon côté client d'une manipulation complexe des validations dans le futur.

Answer 4

Je suis tombé sur ce post après avoir un peu cherché sur knock-out mvc. Bien que je sois d'accord avec le gaspillage de la bande passante du réseau, je suis plutôt séduit par cette ligne de code:

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

C’est un moyen simple et net de générer le modèle de visualisation par knock-out. Quelqu'un at-il utilisé knockout MVC uniquement pour cette fonctionnalité et sans déplacer toute la logique du côté serveur?

Answer 5

La beauté de Knockout.js est que vous pouvez obtenir votre application servi par un simple passage de JSON et en arrière à partir du serveur sans avoir à pousser l'ensemble d'un point de vue que le serveur a dû morceau de loin à produire du HTML.

Il semble contre-intuitif pour remettre tout ça sur le serveur de nouveau! Si cela vous intéresse, vous êtes mieux d'utiliser la syntaxe razor pour accomplir votre liaison en premier lieu.

Ma suggestion serait d'utiliser knockout.js pour faire de votre liaison, de sorte que la liaison a lieu sur le client plutôt que sur le serveur si c'est le but que vous allez pour. Si vous voulez que votre point de vue à être lié aux données sur le serveur, utilisez un rasoir.