Je travaille sur une liste des raisons de mon équipe de passer de Webforms à MVC et j'ai pensé qu'un bon endroit pour commencer était de montrer la "Pourquoi nous devrions migrer" avec un ensemble de choses à la fois classiques ASP et WebForms dans commun.
tel que:
Gardez à l'esprit que mes développeurs ne sont pas le type à mettre en œuvre quelque chose comme MVP W / Out étant poussé et cela fait partie de la raison pour laquelle j'aime MVC (bien que les contrôleurs minces soient une expérience d'apprentissage)
À propos de l'écriture de logiciels plus maintenables avec WebForms: de mon expérience Mise en œuvre d'un modèle de présentation comme MVP dans Webforms pour respecter SRP / augmentation de la maintenabilité / Activer le test d'unité / etc. est beaucoup plus de travail que d'utiliser MVC hors de la boîte (et vous obtenez les mêmes résultats). Cela fonctionne-t-il - oui et j'ai eu du succès avec cette approche dans le passé. Mais si je pouvais plutôt tirer parti d'une approche beaucoup plus naturelle du développement Web cuit à la plate-forme, je le ferais.
Je cherchais quelqu'un à pointer sur des choses que la moyenne de 9-5 développeurs "voulait" de s'éloigner de l'écart de l'ASP classique, mais après leur entrée dans des formes Web n'a jamais suivi. (Encore une fois - la plupart des développeurs que je travaille avec simplement prenaient le désordre qu'ils se sont plaints dans l'ASP classique et l'ont déplacé au code derrière et "pensé" c'était une étape dans la bonne direction).
asp classique - chaque fichier .asp senti ressemble à une grande boule de boue
WebForms - Cette grande boule de boue est passée de la vue sur le "codeBeHind" infâme
5 Réponses :
Une partie du problème est que vous pouvez facilement avoir " Code de spaghetti " et "grandes balles de boue" avec des vues MVC mal écrites - si vous dites que ce sera une "expérience d'apprentissage" en gardant vos contrôleurs minces, alors vous allez avoir du mal à garder vos points de vue propre et bien rangé aussi.
Voir aussi Stackoverflow.com Recherche de "WebForms vs MVC" pour d'autres questions similaires avec le tri d'arguments que vous recherchez.
Modifier en réponse à la modification de la question
OK, les choses que je n'aime pas dans ASP.NET qui ont été supprimées / résolues par ASP.NET MVC:
Ce sont les choses principales pour moi que j'apprécie vraiment lors de la construction de mes sites basés sur MVC.
visualistateenabled = false pour diminuer mes tailles de page.
Dans mon opinion honnête, vous regardez les mauvaises raisons de changer. Passage à ASP.NET MVC ne va réparer aucun de ces problèmes. Il est toujours possible d'avoir une vue géante avec autant, sinon plus, de code spaghetti (ou de boue de boue) comme ASP classique ou WebForms.
Vos points de discussion devraient être davantage dans le sens de la séparation des préoccupations, des URL sympathiques (disponibles dans WebForms également), plus de contrôle sur la page, etc.
Vous pouvez également consulter ce blog de Microsoft:
web Formulaires vs. ASP.NET MVC
... Prenez note de la phrase au bas de la page.
ASP.NET MVC n'est pas les formulaires anti-web
Ils ont tous deux des utilisations appropriées. Passer à un de l'autre à cause d'une mauvaise codage ne va pas aider. Vous pouvez le faire dans un ...
asp.net/webforms semble être similaire (d'emprunter à partir de Joel Spolsky ) A " grandes fuites abstraction "de l'état sur un support essentiellement apatride. Bien que cela (on me dit) était idéal pour les développeurs de Winforms entrant dans le développement Web, "web formulaires" me semblait toujours un paradigme fondamentalement imparfait pour cette raison.
Quand j'ai commencé à (récemment) en savoir plus sur le développement Web (provenant d'un fond de bureau), j'ai été présenté à Python / Django et à Ror et je n'avais vraiment aucune exposition à "Classic" ASP.NET, WebForms , ou j2ee. Je suppose que dans mon naïveté, je suppose que je viens de supposer que tout développement Web (ou au moins tout le développement Web à grande échelle) était basé sur le modèle MVC, il semblait un tel ajustement naturel pour le Web. À venir contre "classique" ASP.NET dans la nature a été .. Ouverture des yeux O_O
En supposant que vous ayez un choix dans la matière, pourquoi voudriez-vous
Il n'y a pas de "classique asp.net". Lorsque les gens parlent de "ASP classique", ils parlent du précurseur VBScript / JScript à ASP.NET, qui a simplement été appelé Asp et était une bête entièrement différente (interprétée, pas de CLR, etc.). Bien entendu, "ASP classique" n'est pas un nom de produit officiel non plus - un terme populaire utilisé pour éviter la confusion avec ASP.NET.
En outre, oui oui oui oui et oui à asp.net étant une "grande abstraction fuite".
la plupart des développeurs que je travaille avec simplement a pris le désordre ils se sont plaints dans l'ASP classique et l'ont déplacé à la code derrière et "pensé" c'était une étape dans la droite direction).
Eh bien, il est une étape dans la bonne direction - mieux que pas de séparation du tout. Bien que oui, c'est toujours souvent une grande boule de boue.
Au cours de mes moments optimistes, je pense que bien, peut-être que cela vient de déplacer la boue ballon au codebehind, mais peut-être qu'elle plante les graines de "HMM, peut-être que le contenu devrait être séparé de la présentation!" dans certains esprits. MVC ou un modèle similaire est bien sûr la destination qu'ils vont finalement atteindre.
(Ne demande pas ce que je pense pendant mes moments non optimistes ... haha.)
Je veux vous avertir que le problème de base que vous signalez n'est pas technique. Avec le type de développeurs que vous décrivez (non motivé, sous-éduqué ou sous-capable), je suggérerais que vous pourriez envisager de ne pas passer au cadre ASP.NET MVC.
Le cadre MVC ne résoudra pas les problèmes d'une équipe lente à apprendre et à utiliser de bons directeurs de conception dans leur travail. Mais le framework MVC dans le formulaire actuel ajoutera une LOI d'apprentissage supplémentaire à leurs plaques. Le framework MVC n'a pas grand-chose de la manière des fonctionnalités de RAD et l'utiliser correctement nécessite une compréhension profonde de la nature de HTTP elle-même.
Une application MVC mal implémentée va être beaucoup pire qu'une application WebFormes mal implémentée. Avec WebForms, vous pouvez obtenir de manière à ne pas comprendre beaucoup sur les interactions plus profondes de HTTP et, telle que le cadre gère la majeure partie de la direction de l'État elle-même.
Avec des programmeurs comme ceux que vous décrivez, vous allez probablement finir par essayer de leur apprendre à faire de la conception OO en même temps que vous essayez de les apprendre également aux internes de HTTP et à les amener à apprendre un nouveau nouveau cadre trop.
C'est assez fort avec des programmeurs très motivés et très compétents.
"... la plupart des développeurs que je travaille avec le désordre ont simplement pris le désordre qu'ils se sont plaints dans le Classic ASP et l'ont déplacé au code derrière et" pensais "c'était une étape dans la bonne direction ..." ... Soyez prudent! Vous décrivez (en grande partie) SharePoint 2007! J'espère que 2010 sera meilleur!