En regardant le framework MVC, il semble que nous ayons besoin de plus de connaissances ASP classiques que les postbacks ASP.NET et Viewstates. Avons-nous reculé vers une logique de code UI + complexe dans le balisage HTML réel?Passons-nous à l'ASP classique en utilisant le framework MVC dans .Net 3.5?
Nous revenons à ne pas essayer de faire abstraction des concepts fondamentaux comme les requêtes HTML et HTTP. Du côté de l'interface utilisateur, cela signifie que les vues sont plus étroitement intégrées à la sortie, ce qui n'est pas une mauvaise chose. le modèle ASP classique s'est traduit par avoir tout étroitement intégré à la sortie, ce qui est une mauvaise chose.
C'est marrant que vous en parliez ... J'ai eu la même conversation avec un collègue aujourd'hui.
Est-ce un pas en arrière? Je ne pense pas ... alors que dans ASP classique vous aviez une logique complexe dans l'interface utilisateur, d'après ce que je peux voir avec MVC, la logique complexe devrait toujours être dans vos objets métier, et toute interaction complexe avec l'objet devrait être fait via le contrôleur.
Le but, encore une fois, d'après ce que je peux voir, est de garder l'interface utilisateur ajustée et ajustée quand il s'agit de la logique métier réelle. Toute distorsion supplémentaire serait causée en rendant l'interface utilisateur plus conviviale, avec les goûts d'AJAX et de JQuery.
Ceci est juste mon observation initiale concernant MVC. C'est une technologie très cool, en particulier avec la façon dont elle se trouve au-dessus de REST, ce qui rend très facile de travailler avec d'autres technologies.
Je suis impatient de l'essayer dans quelques projets futurs!
Le point entier de MVC est pour la séparation du code. Les modèles doivent contenir toute votre logique métier, la vue doit simplement gérer la sortie vers l'utilisateur, et le contrôleur doit les assembler.
On pourrait faire valoir que le paradigme MVC est un pas en arrière si l'on considère le paradigme ASP.NET un pas en avant, je suppose. Personnellement, j'ai toujours pensé qu'il était beaucoup plus facile d'écrire du code séparé propre dans ASP classique, plutôt que .NET où le texte de sortie d'affichage était généralement écrasé dans des blocs de code où il était impossible d'accéder avec un éditeur HTML standard. J'ai toujours pensé que l'architecture ASP.NET était plus axée sur la promotion de .NET que sur l'amélioration de la structure globale de notre application, donc en ce sens MVC est un pas en avant.
Si vous voyez une logique de code complexe dans la vue par rapport aux modèles et aux contrôleurs, c'est peut-être que vous vous en approchez mal. Dans le pur sens du terme, vous devriez pouvoir changer la vue (XML au lieu de HTML) avec un minimum de travail. Cela ne peut se produire que si la logique de données est contenue dans les modèles et si la logique métier est contenue dans les contrôleurs. Par conséquent, si vous avez affiché un panier, il se peut que le code ne contienne que le code qui écrit les quantités et les totaux du produit. La ou les classe (s) du modèle contiendraient les données du produit et le contrôleur effectuerait tout le traitement comme l'ajout de produits et la vérification.