Est-ce que quelqu'un à côté de moi n'obtient pas ASP.NET MVC? [fermé]

Je joue avec ASP.NET MVC depuis le CTP, et j'aime beaucoup de choses qu'ils ont faites, mais il y a des choses que je ne comprends tout simplement pas.

Par exemple, j'ai téléchargé beta1, et je mets en place un petit site / CV / blog personnel avec. Voici un extrait de la vue ViewSinglePost:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

Répugnant! (Notez également que le HTML il y a un espace réservé HTML temporaire, je vais faire un design réel une fois que la fonctionnalité fonctionne) .

Est-ce que je fais quelque chose de mal? Parce que j'ai passé de nombreux jours sombres en ASP classique, et cette soupe d'étiquettes me le rappelle fortement.

Tout le monde prêche comment créer du HTML plus propre. Devine quoi? 1% de toutes les personnes regardent le HTML produit. Pour moi, je m'en fiche si Webforms gâche mon indentation dans le HTML rendu, tant que j'ai un code facile à maintenir ... Ce n'est pas le cas!

Alors, convertissez-moi, un mec des webforms, pourquoi devrais-je abandonner mes pages ASPX bien formées pour cela?

Edit: Gras la ligne "temp Html / css" pour que les gens restent à ce sujet.

Comparé aux formulaires Web, MVC est simultanément une approche de niveau inférieur de la génération HTML avec un meilleur contrôle sur la sortie de la page et une approche de plus haut niveau, davantage axée sur l'architecture. Laissez-moi capturer Web Forms et MVC et montrer pourquoi je pense que la comparaison favorise les Web Forms dans de nombreuses situations - tant que vous ne tombez pas dans certains pièges classiques de Web Forms.

Formulaires Web

Dans le modèle Web Forms, vos pages correspondent directement à la demande de page du navigateur. Ainsi, si vous dirigez un utilisateur vers une liste de livres, vous aurez probablement une page quelque part appelée "Booklist.aspx" vers laquelle vous le dirigerez. Dans cette page, vous devrez fournir tout le nécessaire pour afficher cette liste. Cela inclut le code pour extraire des données, appliquer toute logique métier et afficher les résultats. Si une logique architecturale ou de routage affecte la page, vous devrez également coder la logique architecturale sur la page. Un bon développement de formulaires Web implique généralement le développement d'un ensemble de classes de prise en charge dans une DLL distincte (testable à l'unité). Ces classes géreront la logique métier, l'accès aux données et les décisions d'architecture / de routage.

MVC

MVC adopte une vision plus «architecturale» du développement d'applications Web: en offrant un échafaudage standardisé sur lequel bâtir. Il fournit également des outils pour générer automatiquement des classes de modèle, de vue et de contrôleur au sein de l'architecture établie. Par exemple, dans Ruby on Rails (juste "Rails" à partir de maintenant) et ASP.NET MVC, vous commencerez toujours avec une structure de répertoires qui reflète leur modèle global d'architecture d'application Web. Pour ajouter une vue, un modèle et un contrôleur, vous utiliserez une commande comme "Rails script / generate scaffold {modelname}" (ASP.NET MVC propose des commandes similaires dans l'EDI). Dans la classe de contrôleur résultante, il y aura des méthodes ("Actions") pour Index (afficher la liste), Afficher, Nouveau et Modifier et Détruire (au moins dans Rails, MVC est similaire). Par défaut, ces "

La disposition des répertoires et des fichiers est importante dans MVC. Par exemple, dans ASP.NET MVC, la méthode Index pour un objet «Book» n'aura probablement qu'une seule ligne: «Return View ();» Grâce à la magie de MVC, cela enverra le modèle Book à la page "/View/Books/Index.aspx" où vous trouverez du code pour afficher les livres. L'approche de Rails est similaire bien que la logique soit un peu plus explicite et moins «magique». A Voir la page dans une application MVC est généralement plus simple qu'une page Web Forms parce qu'ils ne sont pas à vous inquiéter autant sur le routage, la logique métier ou le traitement des données.

Comparaison

Les avantages de MVC tournent autour d'une séparation nette des préoccupations et d'un modèle plus propre et plus centré sur HTML / CSS / AJAX / Javascript pour produire votre sortie. Cela améliore la testabilité, fournit une conception plus standardisée et ouvre la porte à un type de site Web plus "Web 2.0".

Cependant, il existe également des inconvénients importants.

Premièrement, s'il est facile de lancer un site de démonstration, le modèle architectural global a une courbe d'apprentissage importante. Quand ils disent "Convention Over Configuration", cela sonne bien - jusqu'à ce que vous vous rendiez compte que vous avez un livre de conventions à apprendre. De plus, il est souvent un peu affolant de comprendre ce qui se passe parce que vous êtes fondez sur la magie plutôt que des appels explicites. Par exemple, ce "Return View ();" appeler ci-dessus? Le même appel peut être trouvé dans d'autres actions mais ils vont à des endroits différents. Si vous comprenez la convention MVCalors vous savez pourquoi cela est fait. Cependant, cela ne peut certainement pas être considéré comme un exemple de bonne dénomination ou de code facilement compréhensible et il est beaucoup plus difficile à comprendre pour les nouveaux développeurs que les formulaires Web (ce n'est pas seulement une opinion: j'ai demandé à un stagiaire d'été d'apprendre Web Forms l'année dernière. et MVC cette année et les différences de productivité ont été prononcées - en faveur des formulaires Web). BTW, Rails est un peu meilleur à cet égard, bien que Ruby on Rails propose des méthodes nommées dynamiquement qui nécessitent également un certain temps d'adaptation.

Deuxièmement, MVC suppose implicitement que vous créez un site Web de style CRUD classique. Les décisions architecturales et en particulier les générateurs de code sont toutes conçues pour prendre en charge ce type d'application Web. Si vous créez une application CRUD et que vous souhaitez adopter une architecture éprouvée (ou simplement n'aimer pas la conception d'architecture), vous devriez probablement envisager MVC. Cependant, si vous faites plus que CRUD et / ou si vous êtes raisonnablement compétent en architecture, MVC peut se sentir comme un carcan jusqu'à ce que vous maîtrisiez vraiment le modèle de routage sous-jacent (qui est considérablement plus complexe que le simple routage dans une application WebForms). Même dans ce cas, j'ai l'impression de toujours me battre contre le modèle et de m'inquiéter des résultats inattendus.

Troisièmement, si vous ne vous souciez pas de Linq (soit parce que vous avez peur que Linq-to-SQL va disparaître, soit parce que vous trouvez Linq-to-Entities ridiculement surproduit et sous-alimenté), vous ne voulez pas non plus suivre cette voie depuis que les outils de création d'échafaudage ASP.NET MVC sont construits autour de Linq (c'était le tueur pour moi). Le modèle de données de Rails est également assez maladroit par rapport à ce que vous pouvez réaliser si vous êtes expérimenté en SQL (et surtout si vous maîtrisez TSQL et les procédures stockées!).

Quatrièmement, les partisans de MVC soulignent souvent que les vues MVC sont plus proches dans l'esprit du modèle HTML / CSS / AJAX du Web. Par exemple, les "HTML Helpers" - les petits appels de code dans votre page vew qui intervertissent le contenu et le placent dans des contrôles HTML - sont beaucoup plus faciles à intégrer avec Javascript que les contrôles Web Forms. Cependant, ASP.NET 4.0 introduit la possibilité de nommer vos contrôles et élimine ainsi largement cet avantage.

Cinquièmement, les puristes de MVC se moquent souvent de Viewstate. Dans certains cas, ils ont raison de le faire. Cependant, Viewstate peut également être un excellent outil et une aubaine pour la productivité. À titre de comparaison, la gestion de Viewstate est beaucoup plus facile que d'essayer d'intégrer des contrôles Web tiers dans une application MVC. Bien que l'intégration des contrôles puisse devenir plus facile pour MVC, tous les efforts actuels que j'ai vus souffrent de la nécessité de créer un code (quelque peu grody) pour relier ces contrôles à la classe Controller de la vue (c'est-à-dire pour travailler autour du modèle MVC ).

Conclusions

J'aime le développement MVC à bien des égards (bien que je préfère de loin Rails à ASP.NET MVC). Je pense également qu'il est important de ne pas tomber dans le piège de penser qu'ASP.NET MVC est un «anti-modèle» des formulaires Web ASP.NET. Ils sont différents mais pas complètement étrangers et il y a certainement de la place pour les deux.

Cependant, je préfère le développement de formulaires Web car, pour la plupart des tâches , il est simplement plus facile de faire les choses (à l'exception de la génération d'un ensemble de formulaires CRUD). MVC semble également souffrir, dans une certaine mesure, d'un excès de théorie. En effet, regardez les nombreuses questions posées ici sur SO par des personnes qui connaissent ASP.NET orienté page mais qui essaient MVC. Sans exception, il y a beaucoup de grincements de dents car les développeurs constatent qu'ils ne peuvent pas effectuer des tâches de base sans sauter à travers des cerceaux ou endurer une énorme courbe d'apprentissage. C'est ce qui rend Web Forms supérieur à MVC dans mon livre: MVC vous fait payer un prix réel pour gagner un peu plus de testabilité ou, pire encore, pour être simplement considéré comme cool parce que vous utilisez ledernière technologie.

Mise à jour: J'ai été fortement critiqué dans la section des commentaires - certains sont assez justes. Ainsi, j'ai passé plusieurs mois à apprendre Rails et ASP.NET MVC juste pour m'assurer que je ne manquais pas vraiment la prochaine grande chose! Bien entendu, cela permet également de garantir que je donne une réponse équilibrée et appropriée à la question. Vous devez savoir que la réponse ci-dessus est une réécriture majeure de ma réponse initiale au cas où les commentaires semblent désynchronisés.

Pendant que je regardais de plus près MVC, j'ai pensé, pendant un petit moment, que je finirais avec un mea culpa majeur. En fin de compte, j'ai conclu que, même si je pense que nous devons dépenser beaucoup plus d'énergie sur l'architecture et la testabilité des formulaires Web, MVC ne répond vraiment pas à l'appel à ma place. Donc, un chaleureux «merci» aux gens qui ont fourni des critiques intelligentes de ma réponse initiale.

Quant à ceux qui ont vu cela comme une bataille religieuse et qui ont sans cesse organisé des inondations de votes négatifs, je ne comprends pas pourquoi vous vous embêtez (plus de 20 votes négatifs en quelques secondes d'intervalle à plusieurs reprises, ce n'est certainement pas normal). Si vous lisez cette réponse et que vous vous demandez s'il y a quelque chose de vraiment "faux" dans ma réponse étant donné que le score est bien inférieur à certaines des autres réponses, soyez assuré que cela en dit plus sur quelques personnes qui ne sont pas d'accord que sur le sens général de la communauté (dans l'ensemble, celle-ci a été votée plus de 100 fois).

Le fait est que de nombreux développeurs ne se soucient pas de MVC et, en effet, ce n'est pas une opinion minoritaire (même au sein de MS comme semblent l'indiquer les blogs).

MVC vous donne plus de contrôle sur votre sortie, et avec ce contrôle augmente le risque d'écrire du HTML mal conçu, de la soupe de balises, etc.

Mais en même temps, vous avez plusieurs nouvelles options que vous n'aviez pas auparavant ...

1. Plus de contrôle sur la page et les éléments de la page
2. Moins de "junk" dans votre sortie, comme le ViewState ou des ID trop longs sur les éléments (ne vous méprenez pas, j'aime le ViewState)
3. Meilleure capacité à faire de la programmation côté client avec Javascript (applications Web 2.0, n'importe qui?)
4. Pas seulement MVC, mais JsonResult est élégant ...

Cela ne veut pas dire que vous ne pouvez faire aucune de ces choses avec WebForms, mais MVC facilite les choses.

J'utilise toujours WebForms lorsque j'ai besoin de créer rapidement une application Web car je peux profiter des contrôles serveur, etc. WebForms masque tous les détails des balises d'entrée et des boutons d'envoi.

WebForms et MVC sont capables de déchets absolus si vous êtes imprudent. Comme toujours, une planification minutieuse et une conception bien pensée aboutiront à une application de qualité, qu'il s'agisse de MVC ou de WebForms.

[Mettre à jour]

Si c'est également une consolation, MVC n'est qu'une nouvelle technologie évolutive de Microsoft. Il y a eu de nombreuses publications sur lesquelles les WebForms resteront non seulement, mais continueront d'être développés pour ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... etc...

Pour ceux qui s'inquiètent de la route empruntée par MVC, je suggère de donner "aux gars" vos commentaires. Ils semblent écouter jusqu'à présent!

La plupart des objections à ASP.NET MVC semblent centrées sur les vues, qui sont l'un des éléments les plus «optionnels» et modulaires de l'architecture. NVelocity , NHaml , Spark , XSLT et d'autres moteurs de vue peuvent être facilement remplacés (et cela devient plus facile avec chaque version). Beaucoup d'entre eux ont une syntaxe BEAUCOUP plus concise pour la logique de présentation et le formatage, tout en donnant un contrôle complet sur le HTML émis.

Au-delà de cela, presque toutes les critiques semblent se résumer au balisage <%%> dans les vues par défaut et à quel point c'est "moche". Cette opinion est souvent ancrée dans le fait d'être habitué à l'approche WebForms, qui ne fait que déplacer la plupart de la laideur ASP classique dans le fichier code-behind.

Même sans faire du code-behind "faux", vous avez des choses comme OnItemDataBound dans Repeaters, qui est tout aussi moche esthétiquement, ne serait-ce que d'une manière différente, que "tag soup". Une boucle foreach peut être beaucoup plus facile à lire, même avec l'incorporation de variables dans la sortie de cette boucle, en particulier si vous arrivez à MVC à partir d'autres technologies non-ASP.NET. Il faut beaucoup moins de Google-fu pour comprendre la boucle foreach que pour comprendre que la façon de modifier ce champ dans votre répéteur est de jouer avec OnItemDataBound (et le nid de rat de vérifier si c'est le bon élément à changer.

Le plus gros problème avec les "spaghettis" basés sur la soupe de balises ASP était plutôt de pousser des choses comme les connexions de base de données juste entre le HTML.

Qu'il soit arrivé à le faire en utilisant <%%> n'est qu'une corrélation avec la nature spaghetti de l'ASP classique, pas une causalité. Si vous conservez votre logique de vue HTML / CSS / Javascript et la logique minimale nécessaire pour faire la présentation , le reste est la syntaxe.

Lorsque vous comparez un bit donné de fonctionnalité à WebForms, assurez-vous d'inclure tout le C # généré par le concepteur et le code C # derrière le code .aspx pour être sûr que la solution MVC n'est vraiment pas, en fait, beaucoup plus simple .

Lorsqu'il est combiné avec une utilisation judicieuse de vues partielles pour des bits reproductibles de la logique de présentation, cela peut vraiment être agréable et élégant.

Personnellement, je souhaite qu'une grande partie du contenu du premier tutoriel se concentre davantage sur cette fin des choses que presque exclusivement sur l'inversion de contrôle, basée sur les tests, etc. Bien que ces autres éléments soient ce à quoi les experts s'opposent, les gars dans les tranchées sont plus susceptibles pour s'opposer à la "soupe de tag".

Quoi qu'il en soit, c'est une plate-forme qui est toujours en version bêta. Malgré cela, il obtient BEAUCOUP plus de déploiement et les développeurs non-Microsoft construisent des éléments réels avec lui que la plupart des technologies bêta de Microsoft. En tant que tel, le buzz a tendance à donner l'impression qu'il est plus avancé que l'infrastructure qui l'entoure (documentation, modèles de guidage, etc.). Le fait d'être véritablement utilisable à ce stade ne fait qu'amplifier cet effet.

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

Vous pouvez créer un autre article vous demandant comment faire cela sans inclure le CSS intégré.

REMARQUE: ViewData.Model devient Model dans la prochaine version.

Et avec l'aide d'un contrôle utilisateur, cela deviendrait

<% Html.RenderPartial("Pager", Model.PagerData) %>

où PagerData est initialisé via un constructeur anonyme dans le gestionnaire d'actions.

edit: Je suis curieux de savoir à quoi ressemblerait votre implémentation WebForm pour ce problème.

Je ne sais pas à quel moment les gens ont cessé de se soucier de leur code.

HTML est l'affichage le plus public de votre travail, il y a BEAUCOUP de développeurs qui utilisent notepad, notepad ++ et d'autres éditeurs de texte brut pour créer de nombreux sites Web.

MVC consiste à récupérer le contrôle des formulaires Web, à travailler dans un environnement sans état et à implémenter le modèle de conception Model View Controller sans tout le travail supplémentaire qui a normalement lieu dans une implémentation de ce modèle.

Si vous voulez contrôler, nettoyer le code et utiliser des modèles de conception MVC, c'est pour vous, si vous n'aimez pas travailler avec le balisage, ne vous souciez pas de la malformation de votre balisage, puis utilisez ASP.Net Web Forms.

Si vous n'aimez pas non plus, vous allez certainement faire à peu près autant de travail dans le balisage.

EDIT Je devrais également déclarer que les formulaires Web et MVC ont leur place, je n'étais en aucun cas en train de dire que l'un était meilleur que l'autre, seulement que chaque MVC a la force de reprendre le contrôle du balisage.

Je pense que certaines choses vous manquent. Tout d'abord, il n'y a pas besoin de Response.Write, vous pouvez utiliser les <%= %>balises. Deuxièmement, vous pouvez écrire vos propres extensions HtmlHelper pour effectuer des actions courantes. Troisièmement, un peu de mise en forme aide beaucoup. Quatrièmement, tout cela serait probablement bloqué dans un contrôle utilisateur pour être partagé entre plusieurs vues différentes et ainsi le balisage global dans la vue principale est plus propre.

Je vous concède que le balisage n'est toujours pas aussi soigné qu'on le souhaiterait, mais il pourrait être considérablement nettoyé grâce à l'utilisation de certaines variables temporaires.

Maintenant, ce n'est pas si mal et ce serait encore mieux si je n'avais pas à le formater pour SO.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

Le gros problème avec MVC est qu'il s'agit d'un cadre conceptuel qui existe depuis longtemps et qu'il s'est avéré être un moyen productif et puissant de créer à la fois des applications Web et des applications de poste de travail qui évoluent horizontalement et verticalement. Il remonte directement à l'Alto et au Smalltalk. Microsoft est en retard à la fête. Ce que nous avons maintenant avec ASP.NET MVC est vraiment primitif, car il y a tellement de rattrapage à faire; mais putain, ils sortent de nouvelles versions rapidement et avec fureur.

Quel était le problème avec Ruby on Rails? Rails est MVC. Les développeurs se sont convertis parce que, par le bouche à oreille, c'est devenu le moyen pour les programmeurs d'être productifs.

C'est une affaire énorme; MVC et l'approbation implicite de jQuery sont des points de basculement pour Microsoft en acceptant que la plate-forme neutre est essentielle. Et ce qui est neutre, c'est que contrairement aux formulaires Web, Microsoft ne peut pas vous enfermer conceptuellement. Vous pouvez prendre tout votre code C # et le réimplémenter entièrement dans un autre langage (disons PHP ou java - vous le nommez) car c'est le concept MVC qui est portable, pas le code lui-même. (Et pensez à quel point il est énorme que vous puissiez prendre votre conception et l'implémenter en tant qu'application de poste de travail avec peu de changement de code, et aucune modification de conception. Essayez cela avec Web Forms.)

Microsoft a décidé que Web Forms ne serait pas le prochain VB6.

S'il vous plaît jeter un oeil à l'article de Rob Conery I Spose Je vais juste le dire: vous devriez apprendre MVC

Les deux principaux avantages du framework ASP.NET MVC par rapport aux formulaires Web sont:

1. Testabilité - L'interface utilisateur et les événements des formulaires Web sont pratiquement impossibles à tester. Avec ASP.NET MVC, les actions du contrôleur de test unitaire et les vues qu'elles rendent sont faciles. Cela entraîne un coût de développement initial, mais des études ont montré que cela est rentable à long terme lorsqu'il est temps de refactoriser et de maintenir l'application.
2. Meilleur contrôle sur le HTML rendu - Vous déclarez que vous ne vous souciez pas du HTML rendu parce que personne ne le regarde. C'est une plainte valable si c'était la seule raison d'avoir un HTML correctement formaté. Il existe de nombreuses raisons de vouloir du HTML correctement formaté, notamment: le référencement, la possibilité d'utiliser plus souvent des sélecteurs d'identifiants (en css et javascript), des empreintes de page plus petites en raison d'un manque de viewstate et des identifiants ridiculement longs (ctl00_etcetcetc).

Maintenant, ces raisons ne rendent pas vraiment ASP.NET MVC meilleur ou pire que les formulaires Web en noir et blanc. ASP.NET MVC a ses forces et ses faiblesses, tout comme les formulaires Web. Cependant, la majorité des plaintes concernant ASP.NET MVC semblent provenir d'un manque de compréhension sur la façon de l'utiliser plutôt que de failles réelles dans le cadre. La raison pour laquelle votre code ne semble pas correct ou ne semble pas correct peut être parce que vous avez plusieurs années d'expérience en matière de formulaires Web à votre actif et seulement 1 à 2 mois d'expérience ASP.NET MVC.

Le problème ici n'est pas tant qu'ASP.NET MVC bascule ou craint, c'est qu'il est nouveau et qu'il y a très peu d'accord sur la façon de l'utiliser correctement. ASP.NET MVC offre un contrôle beaucoup plus fin sur ce qui se passe dans votre application. Cela peut rendre certaines tâches plus faciles ou plus difficiles selon la façon dont vous les abordez.

Hé, j'ai aussi du mal à passer à MVC. Je ne suis absolument pas fan du rendu ASP classique et MVC me rappelle beaucoup de ces jours. Cependant, plus j'utilise MVC, plus cela me pousse. Je suis un gars des webforms (comme beaucoup le sont) et j'ai passé les dernières années à m'habituer à travailler avec des datagrids, etc. Avec MVC, c'est enlevé. Les classes HTML Helper sont la réponse.

Tout récemment, j'ai passé 2 jours à essayer de trouver la meilleure façon d'ajouter la pagination à une "grille" dans MVC. Maintenant, avec les formulaires Web, je pouvais résoudre ce problème en un rien de temps. Mais je dirai ceci ... une fois que j'ai fait construire les classes d'aide à la pagination pour MVC, c'est devenu extrêmement simple à implémenter. Pour moi, encore plus facile que les formulaires Web.

Cela étant dit, je pense que MVC sera beaucoup plus convivial pour les développeurs quand il y aura un ensemble cohérent de HTML Helpers. Je pense que nous allons commencer à voir une tonne de classes d'assistance HTML apparaître sur le Web dans un proche avenir.

C'est drôle parce que c'est ce que j'ai dit la première fois que j'ai vu des formulaires Web.

J'admets que je ne reçois pas encore asp.net MVC. J'essaie de l'utiliser dans un projet parallèle que je fais mais ça va assez lentement.

En plus de ne pas pouvoir faire des choses qui étaient si faciles à faire dans les formulaires Web, je remarque le tag soup. Cela semble vraiment faire un pas en arrière dans cette perspective. J'espère qu'à mesure que j'apprendrai, les choses s'amélioreront.

Jusqu'à présent, j'ai remarqué que la principale raison d'utiliser MVC est d'obtenir un contrôle total sur votre HTML. J'ai également lu que asp.net MVC est capable de servir plus de pages plus rapidement que les formulaires Web et probablement lié à cela, la taille de la page individuelle est plus petite qu'une page de formulaires Web moyenne.

Je ne me soucie vraiment pas de l'apparence de mon HTML tant qu'il fonctionne dans les principaux navigateurs, mais je me soucie de la vitesse à laquelle mes pages se chargent et de la bande passante qu'elles utilisent.

Bien que je sois entièrement d'accord pour dire que c'est un balisage laid, je pense que l'utilisation de la syntaxe de vue laide pour annuler ASP.NET MVC dans son ensemble n'est pas juste. La syntaxe de la vue a reçu le moins d'attention de la part de Microsoft, et je m'attends à ce que quelque chose soit fait à ce sujet bientôt.

D'autres réponses ont abordé les avantages de MVC dans son ensemble, je vais donc me concentrer sur la syntaxe de la vue:

L'encouragement à utiliser Html.ActionLink et d'autres méthodes qui génèrent du HTML est un pas dans la mauvaise direction. Cela sent le contrôle du serveur et, pour moi, résout un problème qui n'existe pas. Si nous allons générer des balises à partir du code, pourquoi se donner la peine d'utiliser HTML? Nous pouvons simplement utiliser DOM ou un autre modèle et créer notre contenu dans le contrôleur. Ok, ça sonne mal, non? Oh oui, séparation des préoccupations, c'est pourquoi nous avons un point de vue.

Je pense que la bonne direction est de rendre la syntaxe de la vue aussi proche que possible du HTML. N'oubliez pas qu'un MVC bien conçu ne doit pas seulement vous permettre de séparer le code du contenu, il doit également vous permettre de rationaliser votre production en demandant à des personnes expertes en mise en page de travailler sur les vues (même si elles ne connaissent pas ASP.NET), puis plus tard, en tant que développeur, vous pouvez intervenir et rendre la maquette de vue réellement dynamique. Cela ne peut être fait que si la syntaxe de la vue ressemble beaucoup au HTML, de sorte que les gens de la mise en page puissent utiliser DreamWeaver ou tout autre outil de mise en page populaire actuel. Vous construisez peut-être des dizaines de sites à la fois et vous devez évoluer de cette manière pour une production efficace. Permettez-moi de vous donner un exemple de la façon dont je pourrais voir la vue "langue" fonctionner:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

Cela présente plusieurs avantages:

• regarde mieux
• plus concis
• pas de changement de contexte funky entre les balises HTML et <%%>
• des mots-clés faciles à comprendre et explicites (même un non-programmeur pourrait le faire - bon pour la parallélisation)
• autant de logique retournée dans le contrôleur (ou modèle) que possible
• pas de HTML généré - encore une fois, cela rend très facile pour quelqu'un d'entrer et de savoir où styliser quelque chose, sans avoir à jouer avec Html. méthodes
• le code contient un exemple de texte qui s'affiche lorsque vous chargez la vue au format HTML brut dans un navigateur (encore une fois, c'est bien pour les personnes de la mise en page)

Alors, que fait exactement cette syntaxe?

mvc: inner = "" - tout ce qui est entre les guillemets est évalué et le code HTML interne de la balise est remplacé par la chaîne résultante. (Notre exemple de texte est remplacé)

mvc: external = "" - tout ce qui est entre les guillemets est évalué et le HTML externe de la balise est remplacé par la chaîne résultante. (Encore une fois, un exemple de texte est remplacé.)

{} - ceci est utilisé pour insérer la sortie à l'intérieur des attributs, similaire à <% =%>

mvc: if = "" - insde the qoutes est l'expression booléenne à évauler. La fermeture du if est l'endroit où la balise HTML se ferme.

mvc: autre

mcv: elseif = "" - ...

mvc: foreach

Maintenant, je ne peux parler que pour moi ici:

OMI, si vous êtes un inconditionnel (quoi que ce soit), la conversion n'est pas pour vous. Si vous aimez les WebForms, c'est parce que vous pouvez accomplir ce dont vous avez besoin, et c'est l'objectif de tous.

Webforms fait un bon travail d'abstraction du HTML du développeur . Si tel est votre objectif, respectez les formulaires Web. Vous disposez de toutes les merveilleuses fonctionnalités "cliquer et glisser" qui ont fait du développement de bureau ce qu'il est aujourd'hui. Il existe de nombreux contrôles inclus (plus une multitude de contrôles tiers) qui peuvent apporter des fonctionnalités différentes. Vous pouvez faire glisser une «grille» directement associée à une source de données depuis votre base de données; il est livré avec une édition intégrée, une pagination, etc.

À l'heure actuelle, ASP.NET MVC est très limité en termes de contrôles tiers. Encore une fois, si vous aimez le développement rapide d'applications, où de nombreuses fonctionnalités sont câblées pour vous, vous ne devriez pas essayer de vous convertir.

Avec tout cela dit, c'est là que ASP.NET brille: - TDD. Le code n'est pas testable, a déclaré Nuff.

• Séparation des préoccupations. C'est la colonne vertébrale du modèle MVC. Je suis pleinement conscient que vous pouvez accomplir cela dans les formulaires Web. Cependant, j'aime la structure imposée. Il était trop facile dans les formulaires Web de mélanger la conception et la logique. ASP.NET MVC permet à différents membres d'une équipe de travailler plus facilement sur différentes sections de l'application.

• Venant d'ailleurs: mon expérience est CakePHP et Ruby on Rails. Donc, il est clair où se situe mon parti pris. Il s'agit simplement de ce avec quoi vous êtes à l'aise.

• Courbe d'apprentissage: pour développer le dernier point; Je détestais l'idée de "templating" pour changer la fonctionnalité de différents éléments. Je n'aimais pas le fait qu'une grande partie de la conception ait été réalisée dans le code derrière le fichier. C'était encore une chose à apprendre, alors que j'étais déjà intimement familier avec HTML et CSS. Si je veux faire quelque chose dans un "élément" sur la page, je m'en tiens à un "div" ou "span", tape un identifiant dessus et je pars. Dans les formulaires Web, je devrais aller chercher comment faire cela.

• État actuel de la «conception» Web: les bibliothèques Javascript comme jQuery sont de plus en plus courantes. La façon dont Web Forms modifie vos ID rend simplement l'implémentation (en dehors de Visual Studio) plus difficile.

• Plus de séparation (conception): étant donné qu'une grande partie de la conception est câblée dans vos contrôles, il serait très difficile pour un concepteur externe (sans connaissances de Web Forms) de travailler sur un projet Web Forms. Web Forms a été conçu pour être la fin et être tout.

Encore une fois, la plupart de ces raisons découlent de ma méconnaissance des formulaires Web. Un projet Web Forms (s'il est conçu correctement) peut avoir «la plupart» des avantages d'ASP.NET MVC. Mais c'est la mise en garde: "Si conçu correctement". Et c'est juste quelque chose que je ne sais pas faire dans les formulaires Web.

Si vous faites un travail remarquable dans Web Forms, que vous êtes efficace et que cela fonctionne pour vous, c'est là que vous devriez rester.

En gros, faites un examen rapide des deux (essayez de trouver une source impartiale [bonne chance]) avec une liste des avantages et des inconvénients, évaluez celui qui correspond à vos objectifs et choisissez en fonction de cela.

En bout de ligne, choisissez le chemin le moins résistant et le plus avantageux pour atteindre vos objectifs. Web Forms est un framework très mature et ne fera que s'améliorer à l'avenir. ASP.NET MVC est simplement une autre alternative (pour dessiner dans Ruby on Rails et les développeurs CakePHP comme moi: P)

Les JSP de Java EE ressemblaient à ceci quand ils ont été proposés pour la première fois - un mauvais code de scriptlet.

Ensuite, ils ont proposé des bibliothèques de balises pour les rendre plus balises HTML. Le problème était que n'importe qui pouvait écrire une bibliothèque de balises. Certains des résultats ont été désastreux, car les gens ont intégré beaucoup de logique (et même de style) dans des bibliothèques de balises générant du HTML.

Je pense que la meilleure solution est la bibliothèque de balises standard JSP (JSTL). C'est "standard", HTML tag-ish, et empêche les gens de mettre de la logique dans les pages.

Un avantage supplémentaire est qu'il préserve cette ligne de démarcation entre les concepteurs Web et les développeurs. Les bons sites que je vois sont conçus par des personnes avec un sens esthétique et une conception conviviale. Ils mettent en page les pages et le CSS et les transmettent aux développeurs, qui ajoutent les bits de données dynamiques. En tant que développeur qui n'a pas ces dons, je pense que nous donnons quelque chose d'important lorsque nous demandons aux développeurs d'écrire des pages Web de la soupe aux noix. Flex et Silverlight souffriront du même problème, car il est peu probable que les concepteurs connaissent bien JavaScript et AJAX.

Si .NET avait un chemin similaire à JSTL, je leur conseillerais de l'examiner.

Je pensais juste que je partagerais à quoi ressemble cet exemple avec le nouveau moteur de vue Razor brillant qui est par défaut depuis ASP .NET MVC 3.

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

Un problème avec ça?
De plus, vous ne devriez pas réellement intégrer vos styles CSS, n'est-ce pas? Et pourquoi vérifiez-vous la nullité à trois endroits au lieu de seulement deux? Un extra divfait rarement mal. Voici comment je procéderais:

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

Je ne peux pas parler directement du projet ASP.NET MVC, mais de manière générale, les frameworks MVC en sont venus à dominer le développement d'applications Web car

1. Ils offrent une séparation formelle entre les opérations de base de données, la «logique métier» et la présentation

2. Ils offrent suffisamment de flexibilité dans la vue pour permettre aux développeurs d'ajuster leur HTML / CSS / Javascript pour fonctionner dans plusieurs navigateurs et les futures versions de ces navigateurs.

C'est ce dernier élément qui est le plus important. Avec les formulaires Web et des technologies similaires, vous comptez sur votre fournisseur pour écrire votre HTML / CSS / Javascript à votre place. C'est puissant, mais vous n'avez aucune garantie que la version actuelle de Webforms fonctionnera avec la prochaine génération de navigateurs Web.

C'est le pouvoir de la vue. Vous bénéficiez d'un contrôle total sur le HTML de votre application. L'inconvénient est que vous devez être suffisamment discipliné pour minimiser la logique de vos vues et garder le code du modèle aussi simple que possible.

Alors, c'est le compromis. Si les Webforms fonctionnent pour vous et que MVC ne l'est pas, continuez à utiliser Webforms

La plupart de ma frustration à ce sujet est simplement de ne pas savoir comment faire les choses «correctement». Depuis sa sortie en avant-première, nous avons tous eu un peu de temps pour regarder les choses, mais elles ont beaucoup changé. Au début, j'étais vraiment frustré, mais le cadre semble suffisamment fonctionnel pour me permettre de créer assez rapidement des interfaces utilisateur extrêmement complexes (lire: Javascript). Je comprends que vous pouvez faire cela avec Webforms comme je le faisais auparavant, mais c'était une énorme douleur dans le cul d'essayer de tout rendre correctement. Souvent, je finirais par utiliser un répéteur pour contrôler la sortie exacte et je me retrouvais également avec beaucoup de désordre de spaghetti que vous avez ci-dessus.

Dans un effort pour ne pas avoir le même désordre, j'ai utilisé une combinaison de domaine, de couches de service et d'un dto pour transférer vers la vue. Mettez cela ensemble avec une étincelle, un moteur de vue et ça devient vraiment sympa. La configuration prend un peu de temps, mais une fois que vous l'avez lancée, j'ai vu un grand pas en avant dans la complexité de mes applications visuellement, mais c'est tellement simple à faire en termes de code.

Je ne le ferais probablement pas exactement comme ça, mais voici votre exemple:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

C'est assez maintenable, testable et a un goût délicieux dans ma soupe de code.

Ce qu'il faut retenir, c'est qu'un code propre est vraiment possible, mais c'est un grand changement par rapport à la façon dont nous faisions les choses. Je ne pense pas que tout le monde le suce encore. Je sais que je suis toujours en train de comprendre ...

Le livre récemment publié de Steve Sanderson «Pro ASP.NET MVC» [1] [2] d'Apress suggère une autre alternative: créer une extension HtmlHelper personnalisée. Son exemple (du chapitre 4 à la page 110) utilise l'exemple d'une liste paginée, mais il peut facilement être adapté à votre situation.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

Vous l'appeleriez dans votre vue avec du code quelque chose comme ceci:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

J'espérais voir un message de Phil Haack, mais ce n'était pas ici, alors je l'ai simplement copié et collé à partir de http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / dans la section commentaires

Haacked - 23 avril 2009 - Rob, vous êtes une émeute! :) Je trouve ça drôle quand les gens écrivent du code spaghetti dans MVC puis disent "regarde! Spaghetti!" Hé, je peux aussi écrire du code spaghetti dans les formulaires Web! Je peux l'écrire en rails, PHP, Java, Javascript, mais pas Lisp. Mais seulement parce que je ne peux encore rien écrire en Lisp. Et quand j'écris du code pour les spaghettis, je ne regarde pas mon assiette d'un air morose en m'attendant à voir des macaronis. Le point que les gens font souvent valoir en le comparant à l'ASP classique est qu'avec l'ASP classique, les gens avaient tendance à mélanger les préoccupations. Les pages auraient une logique de vue avec la gestion des entrées utilisateur mélangées avec le code du modèle et la logique métier, le tout mélangé en un. C'est de ça que parlaient les spaghettis! Le mélange concerne tout dans un grand désordre. Avec ASP.NET MVC, si vous suivez le modèle, vous êtes moins susceptible de le faire. Ouais, il se peut que vous ayez encore un peu de code dans votre vue, mais j'espère que c'est tout le code de vue. Le modèle vous encourage à ne pas y mettre votre code d'interaction utilisateur. Mettez-le dans le contrôleur. Placez votre code de modèle dans une classe de modèle. Là. Pas de spaghettis. C'est maintenant O-Toro Sushi. :)

Moi aussi; Je passerais mon temps sur Silverlight plutôt que sur ASP.NET MVC. J'ai essayé MVC 1.0 et jeté un œil à la dernière version 2.0 Beta 1 il y a quelques jours.

Je (ne peux) pas penser que comment ASP.NET MVC est meilleur que webform. Les arguments de vente de MVC sont:

1. Test de l'unité)
   
2. Séparez la conception (vue) et la logique (contrôleur + modèle)
   
3. Aucune vue et meilleure gestion des identifiants d'élément
   
4. URL RESTful et plus encore ...

Mais webform, en utilisant le code-behind.Theme, Skin et Resource sont déjà parfaits pour séparer la conception et la logique.

Viewstate: la gestion des identifiants client arrive sur ASP.NET 4.0. Je ne suis préoccupé que par les tests unitaires, mais les tests unitaires ne sont pas une raison suffisante pour me tourner vers ASP.NET MVC à partir du formulaire Web.

Peut-être que je peux dire: ASP.NET MVC n'est pas mauvais, mais le formulaire Web suffit déjà.

J'utilise MVC depuis la sortie de l'aperçu 3 et même s'il a encore des difficultés de croissance, cela aide un peu dans le domaine du développement d'équipe. Essayez de faire travailler trois personnes sur une seule page de formulaires Web et vous comprendrez alors le concept de se cogner la tête contre le mur. Je peux travailler avec un développeur qui comprend les éléments de conception sur la page d'affichage et notre dieu Linq résident pour faire fonctionner le modèle pendant que je rassemble tout dans le contrôleur. Je n'ai jamais pu évoluer dans un domaine où la séparation des préoccupations était si facile à réaliser.

Le plus gros argument de vente d'ASP.Net MVC - StackOverflow s'exécute sur la pile MVC.

Cela étant dit ... votre code est tellement plus joli que ce que je fais normalement avec la page d'affichage. De plus, l'un des gars avec qui je travaille travaille sur l'encapsulation de l'aide HTML dans une bibliothèque de balises. Au lieu de <% = Html.RandomFunctionHere ()%> cela fonctionne comme

<hh: randomfunction />

J'espère juste que l'équipe MVC y parviendra à un moment donné, car je suis sûr qu'elle ferait un meilleur travail.

Utilisez un motif de façade pour envelopper toute la logique de toutes les données que vous devez afficher, puis utilisez-le comme générique dans votre vue, puis .... plus de code spaghetti. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Si vous avez besoin de plus d'aide cgardner2020@gmail.com

L'implémentation ASP.NET MVC est horrible. Le produit est nul. J'en ai vu plusieurs démos et j'ai honte de MSFT ... Je suis sûr que les gars qui l'ont écrit sont plus intelligents que moi, mais c'est presque comme s'ils ne savaient pas ce qu'est le Model-View-Controller .

Les seules personnes que je connais qui essaient d'implémenter MVC sont des personnes qui aiment essayer de nouvelles choses de MSFT. Dans les démos que j'ai vues, le présentateur avait un ton d'excuse ...

Je suis un grand fan de MSFT, mais je dois dire que je ne vois aucune raison de me soucier de leur implémentation de MVC. Utilisez Web Forms ou utilisez jquery pour le développement Web, ne choisissez pas cette abomination.

ÉDITER:

L'intention du modèle de conception architecturale Model-View-Controller est de séparer votre domaine de la présentation des règles métier. J'ai utilisé le modèle avec succès dans chaque projet Web Forms que j'ai implémenté. Le produit ASP.NET MVC ne se prête pas bien au modèle de conception architecturale réel.