Y a-t-il une raison pour laquelle j’utiliserais Knockout MVC au lieu de Knockout JS?

Un autre utilisateur a suggéré Knockout MVC pour gérer certains problèmes de publication AJAX. Je lis un peu là-dessus et je vois que c’est une enveloppe autour de Knockout JS . Alors je me demande quelles sont les différences réelles entre les deux? Dois-je m’embêter avec Knockout JS depuis que Knockout MVC existe? Quand utiliserais-je l’un sur l’autre?

Knockout MVC est l’enfant bâtard de WebForms . Il achemine toutes les méthodes de vue via des actions de contrôleur, ce qui signifie que tout ce qui se passe doit rebondir sur le serveur et inversement. Je ne comprends pas pourquoi quiconque prendrait un framework comme knock-out, qui est destiné à être un MVI CLIENT SIDE, et le force à appeler le serveur pour chaque fonction.

De plus, l’exécution de ces méthodes sur le serveur signifie que la vue entière doit être transmise au serveur et renvoyée au client pour chaque appel de fonction. C’est un gaspillage incroyable.

Utiliser Knockout MVC signifie sacrifier tous les avantages de performance du code côté client pour ne pas avoir à écrire de javascript. Le même compromis que les WebForms ont fait. Ce n’est pas bon. C’est un antipattern.

Si Knockout MVC meurt demain, le web sera un meilleur endroit.

J’ai juste rencontré cette question qui a des réponses plutôt négatives. Je vais rapidement append mes deux centimes.

Je viens juste de commencer à utiliser KnockoutJS. Puisque je construis des applications ASP.NET MVC, il m’a semblé logique d’utiliser quelque chose comme Knockout MVC. Pour la plupart, cela semble être une excellente idée. Je ne veux pas passer mon temps à écrire des commentaires javascript et sur mes pages si je peux faire la même chose en utilisant la fonctionnalité .Net que je connais et que j’aime.

Cela dit, oui, KMVC est actuellement limité. Envoyer le modèle complet au serveur est un gros problème. Donc, ce que j’ai fait, c’est de lancer mon propre fork de knock-out-mvc. Les changements ont nécessairement été précipités pour le moment. Mais j’ai maintenant la possibilité de:

  • créer des sous-contextes (avec des modèles ou des composants complètement différents du modèle de vue)
  • transmettre les parties sélectionnées du modèle lors de l’appel du serveur
  • attendre un modèle différent d’un appel que ce qui a été envoyé
  • événements d’incendie autour des appels ajax
  • supporte plus de types d’entrée html5
  • passer des jetons anti-falsification au serveur via des en-têtes (pour les appels ajax)
  • probablement plus j’ai oublié

J’espère revenir bientôt et vraiment nettoyer ce que j’ai fait. Espérons que l’auteur inclura ces modifications dans son code. Si ce n’est pas le cas, je suppose que je garderai ma propre fourchette. De toute façon, il y a de la lumière au bout du tunnel. KMVC pourrait avoir besoin de travail en l’état, mais je pense que le concept en valait vraiment la peine.

Je pense vraiment

Si Knockout MVC meurt demain, le web sera un meilleur endroit.

était un peu dur.

Modifier:

Je regardais les commentaires et regardais à nouveau la question initiale. Ayant fait cela, je pense qu’un peu plus devrait être ajouté à ma réponse:

Tout d’abord, la question initiale était : y a-t-il une raison pour laquelle j’utiliserais Knockout MVC au lieu de Knockout JS? Pour répondre / clarifier (peut-être que je suis juste pointilleux) que: Knockout MVC est un framework conçu pour faciliter l’intégration de KnockoutJS à votre application ASP.NET MVC. Il le fait principalement en utilisant des constructions familières, fortement typées pour générer des tags KnockoutJS. Ce n’est pas un remplacement pour KnockoutJS. Bien sûr, utilisez KnockoutJS. La question est vraiment de savoir s’il faut également utiliser Knockout MVC.

Cela étant dit, le choix est toujours à vous en tant que développeur de choisir quand utiliser différents aspects de tous les outils à votre disposition. Si vous souhaitez gérer un certain aspect des fonctionnalités en effectuant une requête complète sur le serveur, faites-le. Si vous souhaitez effectuer une requête ajax pour récupérer / mettre à jour des données, faites-le. Si vous souhaitez effectuer des fonctionnalités uniquement côté client, faites-le.

L’utilisation de Knockout MVC ne vous empêche pas d’utiliser KnockoutJS à son maximum. L’utilisation de Knockout MVC ne vous empêche pas d’écrire du code JavaScript supplémentaire pour gérer autant de fonctionnalités côté client que vous le souhaitez. Le simple fait que Knockout MVC vous offre un raccourci pour générer des rappels ajax sur le serveur ne signifie pas que vous devez les utiliser. Bien que, si votre application persiste à conserver des données, elle devra appeler à la maison à un moment donné.

Il existe des raisons de créer un moteur d’application à l’aide d’ASP.NET MVC par rapport à l’utilisation d’Apache uniquement pour servir des fichiers HTML et de script statiques. Knockout MVC vous permet de continuer à tirer parti de ces mêmes avantages pour faciliter l’intégration de KnockoutJS.

Je trouve la réponse de Tyrsius un peu trop négative. Knockout MVC est encore en phase de développement, mais de ce que je peux voir, il présente certains avantages et est moins lourd que les Webforms par exemple. Les dépendances de Visiblity reçoivent des descripteurs entièrement sur le client, uniquement lors de l’utilisation de fonctions, un appel est effectué sur le serveur. Lorsque vous travaillez avec des structures de données complexes, il est parfois nécessaire de passer par le serveur, de sorte que Knockout MVC pourrait être un bon moyen d’économiser sur l’écriture d’Ajax.

Il est vrai qu’il envoie toujours le modèle entier dans les deux sens, ce qui donne un peu de temps au lieu de le construire vous-même. Mais je ne l’écrirais pas entièrement. Surtout quand il y a une gestion correcte du côté client pour des validations complexes à l’avenir.

Je suis tombé sur cet article après avoir cherché un peu sur knock-out mvc. Bien que je sois d’accord avec le gaspillage de la bande passante réseau, je suis assez séduit par cette ligne de code:

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

C’est un moyen propre et net de générer le modèle de vue éliminable. Quelqu’un at-il utilisé MVC KO juste pour cette fonctionnalité et sans déplacer toute la logique du côté serveur?

La beauté de Knockout.js réside dans le fait que vous pouvez faire en sorte que votre application soit servie simplement en faisant passer JSON du serveur sans avoir à afficher une vue complète que le serveur a dû créer pour générer du code HTML.

Il semble très contre-intuitif de remettre cela sur le serveur! Si cela vous intéresse, il est préférable d’utiliser la syntaxe de razor pour réaliser votre liaison en premier lieu.

Ma suggestion serait d’utiliser knockout.js pour faire votre liaison afin que la liaison ait lieu sur le client plutôt que sur le serveur si tel est le but que vous visez. Si vous souhaitez que votre vue soit liée à des données sur le serveur, utilisez razor.

De plus, knockout.js est très bon pour l’affichage des données côté client / supprimer / insérer / mettre à jour et le calcul des données côté client. Si une logique métier réelle est aussi simple que cela, nous devons appliquer directement knockout.js.

La vérité est que la logique métier n’est pas toujours simple comme ça. Par exemple, lorsque le client insère un nouvel enregistrement, le système doit vérifier l’authentification de l’utilisateur, définir les valeurs par défaut pour le nouvel object créé en fonction d’une logique métier, d’une formule, etc. logique basée sur des données de firebase database.

Developer est capable de traduire toute la logique métier requirejse en méthodes de script Java dans le modèle de vue knockout.js. Mais de cette façon, la conception viole la règle de gestion de la logique métier centralisée.

Le maintien deviendra un cauchemar pour un tel design.

Résumé, quel choix de cadre dépend réellement des besoins de l’entreprise. Parfois, la performance n’est pas la première considération.

Je peux aussi voir beaucoup de bons cas d’utilisation avec la bibliothèque Knockout MVC. Je pouvais difficilement intégrer KnockoutJS dans notre application Web MVC, justement pour les raisons qui ont été signalées par exemple par @ChinaHelloWorld. Voici quelques cas où je trouve cela extrêmement utile.

  1. Liaisons fortement typées

J’ai aimé les belles méthodes d’aide au typage HTML, qui sont devenues complètement inutiles et compliquées pour la configuration de KnockoutJS. La meilleure chose que je puisse faire est d’attacher manuellement mes atsortingbuts de liaison avec le paramètre supplémentaire des méthodes d’assistance, mais j’ai dû à nouveau utiliser des chaînes magiques. J’aime les helpers fournis par Knockout MVC pour créer des entrées et d’autres éléments avec des liaisons basées sur des expressions C # fortement typées. Cependant, je voudrais mentionner ici que l’atsortingbut name des champs générés me manque, donc je devais le modifier un peu.

  1. Syntaxe de liaison fortement typée (genre de)

Lorsque vous utilisez des liaisons de chaînes pures, il y a toujours de bonnes chances de mal orthographier ou de ne pas connaître exactement le format correct de la liaison que vous souhaitez appliquer. Avec l’API fluide de Knockout MVC et le VS IntelliSense, il est très facile d’appliquer les bonnes liaisons.

  1. (Presque) Conversion automatique des propriétés C # calculées en liaisons calculées

Juste avec l’application du petit atsortingbut [Computed], Knockout MVC peut générer l’expression de liaison correspondante dans la syntaxe KnockoutJS correcte. Celui-ci est très utile aussi je pense.

  1. Aucune duplication de code de vue

De manière classique, je devais avoir la classe viewmodel en code C #, puis (presque) le même code de vue dans JS (avec des observables). Eh bien, C’etait frustrant pour moi, et je suis devenu tres heureux quand j’ai vu la technique utilisee dans Knockout MVC. Cependant, je devais le modifier un peu pour pouvoir l’utiliser avec des modèles de vue très complexes (modèles de vue nesteds, collections, etc.) et pouvoir étendre les modèles de vue Knockout mappés avec par exemple toute méthode JS personnalisée ou une observable calculée. .

Donc, voici au moins quatre très bons points. Et à propos de l’aller-retour de viewmodel: personne n’a dit que quiconque d’entre nous devait utiliser le mécanisme de traitement côté serveur de Knockout MVC. Je ne l’utiliserais pas non plus seulement si une logique métier complexe doit être traitée sur le serveur. Mais dans la plupart des cas, Knockout MVC ne sert qu’à simplifier le processus de liaison et de configuration de MVC Views et KnockoutJS. Donc, je ne comprends pas bien les mauvaises opinions ci-dessus. Je pense que celui qui a écrit ces avis n’a pas fait l’effort d’apprendre au moins les concepts de base de Knockout MVC. Yout définitivement ne devrait pas utiliser Knockout MVC au lieu de KnockoutJS, mais en dehors de KnockoutJS . Comprendre le Javascript et au moins les bases de KnockoutJS est toujours obligatoire dans tous les cas.

Je souhaite que l’auteur continue le développement de Knockout MVC, car outre ces bons points, il existe des fonctionnalités et des améliorations qui le rendraient encore plus puissant.

Dans le modèle .Net MVC, affichez clairement le modèle marquant dans chaque vue / vue partielle avec la balise “@model yourmodel”, qui peut aider le développeur à comprendre ce qui va se passer dans cette vue.

Lorsque vous utilisez le pattern MVVM knockout.js, vous ne verrez probablement aucun modèle de vue .Net, à l’exception des tags comme “data-bind” dans les vues. Cela rendrait la vue et le contrôleur découplés et difficiles à suivre, spécialement pour un nouveau développeur dans une équipe.

Je crois que knockoutMVC peut résoudre de telles difficultés et sauver beaucoup de codes javascript qui rendront le système difficile à maintenir et à comprendre.

Puisque knockoutMVC fait que la conception rest fidèle à l’application d’un modèle de vue côté serveur facile à suivre et à entretenir puisqu’il s’agit du code C #.

Pour un projet d’entreprise, le gestionnaire doit toujours se concentrer sur la facilité de développement, la facilité de maintenance, la mise à niveau, la compréhension et la livraison rapide pour gagner de l’argent.

Sacrifier un peu de performance mais simplifier les choses, la cohérence au niveau du client et du côté serveur devrait être un élément clé. Javascript est un gros problème de maintenance.

Est-ce vraiment une question de renvoyer l’ensemble du modèle de vue au serveur? Si c’est le cas, nous pouvons diviser un grand modèle en plusieurs petits modèles.

Vous avez toujours la performance si vous n’utilisez pas les fonctions générées par komvc. Comme l’a dit Nigel, la génération de page initiale devra toujours être générée par un serveur. Vous pouvez toujours append des scripts utilisateur et créer des fonctions côté client qui n’auront pas besoin de revenir au serveur. C’est un outil qui donne un peu de productivité au développeur. La comparaison avec les formulaires Web sur la performance est certainement exagérée. Les gens, c’est un outil qui vous aide à respecter votre échéance.

J’appendai mes 2 centimes en faveur de knockoutjs, bien que ce soit peu compliqué à écrire par rapport à knockout MVC, le bénéfice que vous obtenez est énorme en matière de réutilisabilité. Le code client peut également fonctionner en harmonie avec d’autres technologies.

Gardant de côté la perspective de la sécurité, je pense personnellement que jockout est une façon de compliquer asp.net MVC et qu’il devrait être utilisé tel quel (knockout js) avec des applications RESTful pures telles que asp.net webapi.

Knockout MVC est une puissante extension pour ASP .NET MVC qui vous permet d’implémenter la fonctionnalité client du site Web directement sur votre projet .NET en utilisant des fluentAPI conviviaux pour les développeurs sans Javascript et en supprimant beaucoup de code répétitif.
knockout MVC est le même que le codage ASP .NET MVC razor et vous obtenez la fonctionnalité client sans tracas supplémentaire.
Vous n’aurez pas à coder un modèle de vue et des lignes de code de liaison.
J’ai utilisé koMVC sur la plupart de mes sites Web et la réduction du temps de développement, la facilité de maintenance et la courbe d’apprentissage minimale sont des avantages considérables.
Je vous suggère de vérifier leur site Web et d’essayer quelques exemples en direct. http://knockoutmvc.com
Il ne faudra pas longtemps pour que vous en tombiez amoureux.

MVC est un modèle d’architecture qui se divise en trois composants: modèle, vue et contrôleur.

KnockoutJS fonctionne mieux avec l’architecture MVC car la liaison de données du framework nécessite l’utilisation d’un contrôleur. Il existe des frameworks tels qu’AngularJS qui se concentrent davantage sur le front-end et par conséquent, ils fonctionnent mieux avec le modèle d’architecture MVVM (modèle, vue, modèle de vue). Leurs fonctionnalités de liaison de données ne nécessitent pas non plus l’utilisation d’un contrôleur, ce qui réduit la scope de la liaison.