ASP.NET MVC> ASP.NET WebForms, pourquoi?

Question

J'ai maintenant terminé ma première application web en utilisant ASP.NET MVC et dans l'ensemble, je ne comprends toujours pas pourquoi cela obtient tous les éloges et la gloire. Peut-être que je suis têtu. Je sais que ce qui rend MVC génial, c'est qu'il force la séparation entre la couche de présentation et l'objet métier ou la couche de données avec son fonctionnement sans état. Je sais aussi que lorsque vous travaillez avec la vue, il apparaît que le code est moins lisible (voir mon exemple ci-dessous).

Donc, je suppose que ma question est ... Si la séparation est la préoccupation, pourquoi ne pas simplement séparer.

Web Forms Afficher le code:

//UI 
<h2><asp:Label ID="lblPageHeader" runat="server" /></h2> 

Web Forms code Derrière:

//CODE BEHIND 
this.lblPageHeader.Text = myObject.Header; 

code MVC Voir:

//UI 
<h2><%= Html.Encode(Model.PageTitle) %></h2> 

MVC Code de contrôleur:

index = new Index 
{ 
    PageText = sb.ToString(), 
    PageTitle = "WELCOME" 
}; 
return View(index); 

Encore une fois, je pourrais être têtu, mais l'une des choses que j'ai vraiment aimé dans WebForms est la facilité dans la définition des propriétés d'objet comme sources de données et les valeurs de texte. Il semble que ce soit complètement différent dans MVC et moins lisible, ce qui me fait réfléchir à la maintenance à long terme. Après avoir examiné les modèles dactylographiés, je pense que la lisibilité du code est sensiblement améliorée.

Answer 1

ASP.NET MVC Best Practices, Tips and Tricks

Je voudrais écrire:

<h2><%= Html.Encode(Model.Title) %></h2> 

(il est possible avec une aide de vues dactylographiées)

au lieu de

<h2><%= Html.Encode((MyApp.MyObject)ViewData["PageObject"].Header) %></h2> 

Je pense qu'il est tout au sujet de la façon dont vous utilise le. Si vous êtes plus heureux avec ASP.NET classique, ce sera peut-être une meilleure idée de s'en tenir à cela. De plus, vous pouvez également prendre de bonnes choses à partir du monde ASP.NET MVC (comme la séparation de l'interface utilisateur et de la logique) et l'amener à l'ASP.NET classique.

Answer 2

Bien sûr, un exemple simple va être très clair et lisible, peu importe comment vous le faites. Censément, l'avantage de MVC devient plus apparent que vous augmentez la complexité.

En outre, il s'avère que le modèle de formulaires Web n'est pas idéal pour les sites Internet publics à fort volume. ViewState et le cycle de vie de page coûteux dans un site de formulaires Web normal peuvent faire de l'évolutivité un défi (pas impossible, mais difficile). En revanche, sur un ra les utilisateurs de site net ont généralement beaucoup plus de bande passante en amont (ViewState fonctionne mieux) et le volume est beaucoup mieux contrôlé. Donc les webforms fonctionnent vraiment bien là-bas.

Answer 3

Je suis également attentiste à l'égard de ASP.NET MVC (avec le framework Entity et WPF pour des raisons de différences).Je suis un grand fan de MVC en général, mais je suis un peu préoccupé par l'emballage de quelque chose comme un objectif général comme un cadre de développement web dans les contraintes d'un modèle. Un modèle très utile mais toujours un seul parmi beaucoup d'autres.

Un développeur expérimenté peut implémenter MVC dans pratiquement n'importe quelle langue. Donc, MVC peut être un excellent moyen d'empêcher les développeurs moins qualifiés (nous sommes tous à un moment donné, comme lorsque vous venez d'apprendre un cadre) de faire des erreurs flagrantes. Puisque le modèle fonctionne bien dans un large éventail de scénarios, cela pourrait en faire un avantage net. D'autre part, pour les développeurs experts, il peut s'avérer être comme des roues d'entraînement sur un cycliste olympique ... Redondant et plus d'une douleur que d'un avantage.

Answer 4

Il est vrai que vous devez en faire plus dans MVC pour obtenir certaines des mêmes fonctionnalités de base très automatiques auxquelles vous êtes habitué dans WebForms.

Cependant, à long terme, vous obtenez plus de contrôle.

La chose principale brisée à propos WebForms est le tout scénario postback, et combien de cerceaux vous devez sauter à travers la mise en œuvre WebForms simples quelque chose n'a pas pensé. Un excellent exemple est ma question liée à WebForms: Is there any native way in ASP.NET to do a "success message"?

Je voulais faire un message «Record Saved» ou «New Record Added» dans une application WebForms. Il s'avère que vous devez faire des choses vraiment effrayantes juste pour obtenir cette fonctionnalité simple à travailler, car ils n'ont pas un moyen normal de le faire dans WebForms, et pour faire une méthode personnalisée, vous vous battez contre les fonctionnalités cachées en PostBack.

Dans MVC, cela ne poserait aucun problème. Vous devez toujours écrire la fonctionnalité manuellement, mais vous aurez beaucoup plus de contrôle sur l'état de votre page.

Answer 5

Je crois que vous ne pouvez ressentir la différence qu'après avoir participé à un grand projet et avoir vu le nombre de dégâts que WebForms pourrait causer. Lorsque vous avez vu une page contenir plusieurs composants, les contrôles utilisateur, certains d'entre eux vivent une vie indépendante comme cacher/montrer ou activer/désactiver eux-mêmes, toutes ces règles passant par plusieurs couches de contrôle qui ne peuvent pas être tracées jusqu'à ce que vous ayez été dans un projet pendant de longues années (ou du moins avoir fumé quelque chose de bien avant de plonger avec le débogueur :)), vous commencez à apprécier la possibilité d'un flux de contrôle clairement défini quand vous voyez comment vos données définissent quels composants avec quelles propriétés sont rendues sur une page.

J'ai aussi aimé WebForms pendant longtemps. J'ai également détesté les premières semaines/mois MVC pour exactement les mêmes raisons que vous avez mises en avant. Après avoir codé et comparé l'expérience, j'ai commencé à apprécier MVC. Néanmoins, il existe certaines zones où l'approche MVC serait beaucoup plus compliquée et créerait plus de désordre que ne le ferait WebForms.

Ça viendra avec le temps. Pas vraiment longtemps. :)

Answer 6

Pas une réponse complète, mais une grande préoccupation est testabilité des formulaires ASP.NET, ou l'absence de celle-ci. Test de la logique de l'interface utilisateur de ce qui est affiché et comment. Avec ASP.NET Forms, il ne vous reste plus que le codebehind.

Maintenant, MVC n'est pas pour tout le monde. Vous pouvez vous intéresser à MVP (Model-View Presenter) pour ASP.NET Forms car il utilise des concepts MVC très similaires, sauf que Presenter contrôle les modifications internes de la vue.

Mais, testabilité est vraiment un gros plus pour tester votre code. Tels que whawt se produit lorsque quelqu'un clique sur la méthode/l'action ChangePassword:

[TestClass] 
public class AccountControllerTest 
{ 

    [TestMethod] 
    public void ChangePasswordPostRedirectsOnSuccess() 
    { 
     // Arrange 
     AccountController controller = GetAccountController(); 

     // Act 
     RedirectToRouteResult result = 
      (RedirectToRouteResult)controller.ChangePassword(
       "oldPass", "newPass", "newPass"); 

     // Assert 
     Assert.AreEqual("ChangePasswordSuccess" 
      , result.RouteValues["action"]); 
    } 
} 

Answer 7

Ce qui est génial ASP.NET MVC est qu'il est ne pas essayer de cacher comment fonctionne HTTP. Pour bien comprendre ASP.NET MVC, vous devez comprendre les technologies du Web.

Bien que webforms sont adéquats aussi longtemps que vous travaillez à leurs forces, ils sont en fin de compte une abstraction très qui fuit quand vous ne le faites pas. Alors que les inconvénients de viewstate ont été bien discutés à ce stade, je pense que c'est la tentative extrêmement imprudente d'imiter le comportement de Winforms qui est le défaut sous-jacent - viewstate est simplement un produit de cela.

Les contrôles web qui sont livrés avec ASP.NET laissent aussi beaucoup à désirer (l'enfer a) comme quelqu'un qui a essayé de construire un site Web accessible peut attester. Les contrôles Web montrent un manque total de compréhension de la façon dont le développement frontend est fait, et franchement, c'est une honte.

Avec ASP.NET MVC tout ce non-sens est supprimée. Vous n'êtes pas à l'abri des protocoles HTTP, HTML, CSS ou JavaScript. Si vous venez à la fête avec ces technologies, le framework disparaît et vous permet de les exploiter. Sinon, heureusement, cela n'essaie pas de vous aider à prétendre qu'ils n'existent pas.

Answer 8

Je pense qu'il dépend beaucoup de votre arrière-plan. Si vous êtes déjà familier avec quelque chose comme Ruby-rails et/ou Django, asp.net mvc a beaucoup plus de sens.

Aussi, si vous avez fait des sites Web en HTML et CSS depuis longtemps, Mvc est beaucoup mieux que vous avez le contrôle total sur votre sortie html.

Si vous êtes à l'aise avec asp.net simplement continuer à l'utiliser, ça ne va pas loin :).

Answer 9

Une chose (de beaucoup) que j'aime MVC est qu'il se débarrasse des contrôles de serveur Web. Bien qu'ils soient considérés par beaucoup comme une excellente chose à propos de WebForms, j'ai constaté qu'une fois que vous avez passé les opérations de base, ils deviennent un cauchemar. Essayer de jongler les événements de liaison de données sur des grilles avec des publications et tout le reste devient la version OO du code spaghetti. MVC vous demandera d'avoir une meilleure connaissance des locataires de base du développement web (GET, POST, REQUEST, HTML, CSS, JAVASCRIPT), le résultat sera bien meilleur. Voir mon graphique de la façon dont je pense MVC fonctionne :-)

alt text http://www.baseestate.com/webformsmvc.gif