Existe-t-il une raison pour laquelle je voudrais utiliser Knockout MVC au lieu de Knockout JS?
Un autre utilisateur suggéré Knockout MVC pour gérer certains problèmes d'affichage AJAX Je lis un peu dessus et je vois que c'est un wrapper autour de Knockout JS . Alors je me demande quelles sont les vraies différences entre les deux? Dois-je m'embêter avec Knockout JS puisque Knockout MVC existe Quand devrais-je utiliser l'un sur l'autre?
Knockout MVC est l'enfant bâtard de WebForms . Il achemine toutes les méthodes de modèles de vue via des actions du contrôleur, ce qui signifie que tout ce qui se passe doit être renvoyé au serveur, puis inversement. Je ne comprends pas pourquoi quiconque prendrait un framework tel que knockout, qui est destiné à être MVI CLIENT SIDE, et le forcerait à appeler le serveur pour chaque fonction.
De plus, l'exécution de ces méthodes sur le serveur signifie que le tout viewmodel doit être transmis au serveur, puis au client, pour chaque appel de fonction. Ceci est incroyablement inutile.
Utiliser Knockout MVC signifie sacrifier tous les avantages en termes de performances du code côté client pour ne pas avoir à écrire du javascript. Le même compromis WebForms fait. Ce n'est pas un bon. C'est un anti-modèle.
Si Knockout MVC meurt demain, le Web sera un meilleur endroit.
Je viens de croiser cette question qui a des réponses assez négatives. Je vais rapidement ajouter ma valeur de deux cents.
Je viens juste de commencer à utiliser KnockoutJS. Depuis que je crée des applications ASP.NET MVC, il m'a semblé logique d'utiliser quelque chose comme Knockout MVC. Pour la plupart, cela semble être une bonne idée. Je ne veux pas passer de temps à écrire des commentaires javascript et <!-- ko --> dans 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, il y a des limites à la CVMV pour le moment. Envoyer le modèle entier au serveur est un gros travail. Donc, ce que j'ai fait est de lancer ma propre fourchette de knockout-mvc. Les changements ont été nécessairement précipités pour le moment. Mais j'ai maintenant la capacité de:
- créer des sous-contextes (avec des modèles ou des composants complètement différents du modèle de vue)
- retransmet les parties sélectionnées du modèle lors de l'appel du serveur
- attendez d'un appel un modèle différent de celui qui a été envoyé
- événements d'incendie autour des appels ajax
- supporte plus de types d'entrées html5
- transmettre des jetons anti-contrefaçon au serveur via des en-têtes (pour les appels ajax)
- probablement plus j'ai oublié
J'espère pouvoir revenir bientôt et vraiment nettoyer ce que j'ai fait. Espérons que l'auteur inclura ces modifications dans son code. Si non, je suppose que je vais continuer ma propre fourchette. De toute façon, il y a de la lumière au bout du tunnel. Le KMVC pourrait avoir besoin de travailler tel quel, 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 encore quelle était la question initiale. Ayant fait cela, je pense qu’un peu plus devrait être ajouté à ma réponse:
Premièrement, la question initiale était Y a-t-il une raison pour laquelle je voudrais utiliser Knockout MVC au lieu de Knockout JS? Pour répondre/préciser (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. Pour ce faire, il utilise principalement des constructions connues et fortement typées pour générer des balises KnockoutJS. Ce n'est pas un remplacement pour KnockoutJS. Bien sûr, utilisez KnockoutJS. La question est vraiment de savoir s'il faut utiliser Knockout MVC aussi.
Cela étant dit, vous avez toujours le choix, en tant que développeur, de choisir le moment d'utilisation des différents aspects de tous les outils à votre disposition. Si vous souhaitez gérer un certain aspect de la fonctionnalité 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 utiliser uniquement des fonctionnalités côté client, faites-le.
Utiliser Knockout MVC n’empêche pas d’utiliser KnockoutJS au maximum. L'utilisation de Knockout MVC n'empêche pas [] l'écriture de javascript supplémentaire pour gérer autant de fonctionnalités côté client que vous le souhaitez. Simplement parce que Knockout MVC vous fournit 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 conserve des données, elle devra appeler à la maison à un moment donné.
Il existe des raisons de créer un backend d’application à l’aide d’ASP.NET MVC par rapport à la simple utilisation d’Apache pour la gestion de fichiers HTML et de scripts statiques. Knockout MVC vous permet de continuer à profiter de ces mêmes avantages pour vous aider à intégrer KnockoutJS.
Je trouve la réponse de Tyrsius un peu trop négative. Knockout MVC en est encore à ses débuts, mais d'après ce que je vois, il présente certains avantages et est moins lourd en serveurs que Webforms, par exemple. Les dépendances de visibilité sont entièrement traitées par le client, uniquement lorsque des fonctions sont utilisées pour appeler le serveur. Lorsque vous travaillez avec des structures de données complexes, il est parfois nécessaire de passer par le serveur de toute façon. Knockout MVC peut donc être un bon moyen d'économiser sur l'écriture de nombreuses tâches effectuées avec Ajax.
Il est vrai que le modèle entier est toujours envoyé dans les deux sens, ce qui génère des frais généraux au lieu de le construire vous-même. Mais je ne l'écrirais pas entièrement. Surtout quand il y a une manipulation appropriée côté client pour les validations complexes à l'avenir.
Je suis tombé sur ce post après avoir un peu cherché à propos de knock-out mvc. Bien que je sois d’accord avec le gaspillage de bande passante réseau, je suis tout à fait 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 visualisation à élimination directe. Quelqu'un at-il utilisé knockout MVC uniquement 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 obtenir votre application servie en passant simplement JSON du serveur sans avoir à afficher une vue complète que le serveur a dû supprimer pour générer du code HTML.
Il semble très contre-intuitif de remettre cela sur le serveur! Si cela vous intéresse, vous feriez mieux d'utiliser la syntaxe de rasoir pour accomplir votre liaison en premier lieu.
Ma suggestion serait d'utiliser knockout.js pour faire votre liaison de telle sorte que la liaison se fasse sur le client plutôt que sur le serveur si tel est l'objectif que vous visez. Si vous souhaitez que votre vue soit liée aux données sur le serveur, utilisez rasoir.
De plus, knockout.js sure est très bon pour l’affichage/la suppression/l’insertion/la mise à jour des données côté client et le calcul des données côté client. Si une véritable logique métier est aussi simple que cela, nous devons appliquer knockout.js directement.
La vérité est que la logique métier n’est pas toujours aussi simple. Par exemple, lorsque le client insère un nouvel enregistrement dans la vue, le système doit éventuellement vérifier l'authentification de l'utilisateur, définir les valeurs par défaut du nouvel objet créé en fonction d'une formule ou d'une logique commerciale, etc. Tout ceci doit néanmoins être effectué côté serveur. logique basée sur les données de la base de données.
Le développeur peut traduire toute la logique métier requise en méthodes de script Java dans le modèle de vue de knockout.js. Mais de cette manière, la conception enfreint la règle de gestion de la logique métier centralisée.
La maintenance deviendra un cauchemar pour une telle conception.
En résumé, le choix du cadre dépend vraiment des besoins de l’entreprise. Parfois, la performance n'est pas la première considération.
Je peux également voir de nombreux cas d'utilisation intéressants avec la bibliothèque Knockout MVC. Je pouvais difficilement intégrer KnockoutJS dans notre application Web MVC, précisément pour des raisons qui avaient été signalées, par exemple, @ChinaHelloWorld. Voici quelques cas où je trouve cela extrêmement utile.
- Liaisons fortement typées
J'ai aimé les méthodes de Nice helpers HTML fortement typées, qui sont devenues complètement inutiles et désordonnées lors de la création de KnockoutJS. La meilleure chose à faire est d’attacher manuellement mes attributs de liaison avec le paramètre supplémentaire des méthodes d’aide, mais j’ai encore dû utiliser des chaînes magiques. J'aime les aides fournies par Knockout MVC pour la création d'entrées et d'autres éléments avec des liaisons fortement typées, basées sur l'expression C #. Cependant, ici, je voudrais mentionner que l’attribut name des champs générés me manque, alors j’avais besoin de le modifier un peu.
- Syntaxe de liaison fortement typée (en quelque sorte)
Lorsque vous utilisez des liaisons pures, il y a toujours de bonnes chances que le nom de la liaison que vous souhaitez appliquer soit mal orthographié ou mal connu. Avec les API fluides de Knockout MVC et VS IntelliSense, il est très facile d'appliquer les liaisons correctes.
- Conversion (presque) automatique des propriétés C # calculées en liaisons calculées
Juste avec l'application du petit attribut [Computed], Knockout MVC peut générer l'expression de liaison correspondante dans la syntaxe correcte de KnockoutJS. Celui-ci est très utile aussi, je pense.
- Pas de duplication du code du modèle de vue
De manière classique, j'avais besoin d'avoir la classe viewmodel dans le code C #, puis (presque) le même code viewmodel dans JS (avec observables). C’était frustrant pour moi, et j’ai été extrêmement heureux de voir la technique utilisée 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 imbriqués, collections, etc.) et pour pouvoir étendre les modèles de vue Knockout mappés avec, par exemple, toute méthode JS personnalisée requise ou calculée. .
Donc, voici au moins quatre très bons points. Et à propos des allers-retours viewmodel: personne n’a dit que nous devions utiliser le mécanisme de traitement côté serveur de Knockout MVC. Je ne l'utiliserais pas non plus, uniquement s'il existe une logique métier complexe qui doit vraiment être traitée sur le serveur. Mais dans la plupart des cas, Knockout MVC sert uniquement à 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 l'auteur de ces opinions n'a pas pris l'effort d'apprendre au moins les concepts de base de Knockout MVC. Yout definetely ne devrait PAS utiliser Knockout MVC au lieu de KnockoutJS, mais à part KnockoutJS. Comprendre le javascript et au moins les bases de KnockoutJS reste obligatoire dans tous les cas.
Je souhaite que l'auteur poursuive le développement de Knockout MVC, car outre ces avantages, il existe certaines fonctionnalités et améliorations qui le rendraient encore plus puissant.
Dans le modèle .Net MVC, le modèle de vue marquant clairement dans chaque vue/vue partielle clairement avec la balise "@model yourmodel", ce qui peut aider le développeur à comprendre ce que fera cette vue.
Lorsque vous utilisez le modèle MVVM de knockout.js, vous ne verrez probablement aucun modèle de vue .Net, à l'exception des balises telles que "liaison de données" dans les vues. Cela rendrait la vue et le contrôleur non couplés et difficiles à suivre, spécialement pour un nouveau développeur dans une équipe.
Je pense que knockoutMVC peut résoudre de telles difficultés et économiser beaucoup de codes javascript, ce qui rendra le système difficile à maintenir et à comprendre.
Depuis que knockoutMVC fait en sorte que la conception reste fidèle à l’application, le modèle de vue côté serveur est facile à suivre et à maintenir car il s’agit du code C #.
Pour un projet d'entreprise, le responsable doit toujours se concentrer sur la facilité de développement, de maintenance, de mise à niveau, de compréhension et de livraison rapide.
Sacrifiez un peu les performances mais simplifiez-vous les choses, la cohérence côté client et côté serveur devrait être un élément clé. Javascript est un gros problème de maintenance.
Est-ce vraiment une question de renvoyer le modèle de vue dans son intégralité côté serveur? Si tel est le cas, nous pouvons diviser un grand modèle en plusieurs petits modèles.
Vous avez toujours les performances si vous n'utilisez pas les fonctions générées par komvc. Comme Nigel l'a dit, la génération initiale de pages devrait toujours être générée par le serveur. Vous pouvez toujours ajouter des scripts utilisateur et créer des fonctions côté client qui n'ont pas besoin de retourner sur le serveur. C'est un outil qui donne au développeur un peu de productivité. La comparaison avec les formulaires Web sur les performances est certainement exagérée. Chers amis, c’est un outil qui vous aidera certainement à respecter votre échéance.
Knockout MVC est une extension puissante pour ASP .NET MVC qui vous permet d’implémenter la fonctionnalité client du site Web directement sur votre projet .NET en utilisant des API fluent conviviales pour les développeurs sans Javascript et en supprimant une grande partie du code répétitif et dupliqué.
knockout MVC est identique à coder ASP .NET MVC Razor et vous obtenez la fonctionnalité client sans aucune difficulté supplémentaire.
Vous n’aurez pas à coder un modèle de vue et des lignes de code de liaison.
J'utilise 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 très rentables.
Je vous suggère de consulter leur site Web et d’essayer quelques exemples concrets. http://knockoutmvc.com
Il ne vous faudra pas longtemps pour en tomber amoureux.
J'ajouterai mes 2 centimes en faveur de knockoutjs, bien que ce soit un peu compliqué à écrire par rapport au knock-out MVC, le bénéfice que vous obtenez est énorme en termes de réutilisation. Le code client peut également fonctionner de manière harmonieuse avec d’autres technologies.
En gardant de côté la perspective de sécurité, j'estime personnellement que knockout js est un moyen de compliquer aspCVM.net et qu'il devrait être utilisé tel quel (knockout js) avec des applications RESTful pures telles que asp.net webapi.
MVC est un modèle d'architecture qui se sépare en trois composants, Modèle, Vue et Contrôleur.
KnockoutJS fonctionne mieux avec l’architecture MVC car la liaison de données de la structure nécessite l’utilisation d’un contrôleur. Il existe des structures telles que AngularJS qui se concentre davantage sur le système frontal et fonctionnent donc mieux avec le modèle d'architecture MVVM (modèle, vue, modèle de vue). Leurs fonctions de liaison de données n’exigent pas non plus l’utilisation d’un contrôleur, ce qui réduit la portée de la liaison.