Le plus grand avantage de l'utilisation d'ASP.Net MVC par rapport aux formulaires Web

Quels sont certains des avantages de l'utilisation de l'un par rapport à l'autre?

Les principaux avantages d' ASP.net MVC sont:

1. Permet le contrôle total sur le HTML rendu.

2. Fournit une séparation nette des problèmes (SoC).

3. Active le développement piloté par les tests (TDD) .

4. Intégration facile avec les frameworks JavaScript.

5. Suite à la conception de la nature apatride du Web.

6. URL RESTful qui permettent le référencement.

7. Aucun événement ViewState et PostBack

Les principaux avantages de ASP.net Web Form sont:

1. Il fournit le développement RAD

2. Modèle de développement facile pour les développeurs issus du développement winform.

ASP.NET Web Forms et MVC sont deux frameworks Web développés par Microsoft - ce sont tous deux de bons choix. Aucun des frameworks Web ne doit être remplacé par l'autre et il n'est pas prévu de les «fusionner» en un seul framework. Le support et le développement continus sont effectués en parallèle par Microsoft et aucun des deux ne «disparaîtra».

Chacun de ces frameworks Web offre des avantages / inconvénients - dont certains doivent être pris en compte lors du développement d'une application Web. Une application Web peut être développée à l'aide de l'une ou l'autre des technologies - cela peut faciliter le développement d'une application particulière en sélectionnant une technologie par rapport à l'autre et vice versa.

Formulaires Web ASP.NET:

• Le développement prend en charge l'état • Donne l'illusion qu'une application Web est consciente de ce que l'utilisateur a fait, comme les applications Windows. Ie Rend la fonctionnalité «assistant» un peu plus facile à implémenter. Les formulaires Web font un excellent travail pour cacher une grande partie de cette complexité au développeur.
• Développement rapide d'applications (RAD) • La capacité de «se lancer» et de commencer à fournir des formulaires Web. Ceci est contesté par une partie de la communauté MVC, mais poussé par Microsoft. En fin de compte, cela dépend du niveau d'expertise du développeur et de ce avec quoi il est à l'aise. Le modèle de formulaires Web a probablement moins de courbe d'apprentissage pour les développeurs moins expérimentés.
• Boîte à outils de contrôle plus grande • ASP.NET Web Forms offre une boîte à outils (contrôles Web) beaucoup plus grande et plus robuste, tandis que MVC propose un ensemble de contrôles plus primitif reposant davantage sur des contrôles côté client riches via jQuery (Javascript).
• Mature • Il existe depuis 2002 et il existe une abondance d'informations concernant les questions, les problèmes, etc. Offre plus de contrôle par des tiers - il faut tenir compte de vos boîtes à outils existantes.

ASP.NET MVC:

• Séparation des problèmes (SoC) • D'un point de vue technique, l'organisation du code au sein de MVC est très propre, organisée et granulaire, ce qui facilite (espérons-le) pour une application Web une évolution en termes de fonctionnalités. Favorise une excellente conception du point de vue du développement.
• Intégration plus facile avec les outils côté client (outils d'interface utilisateur riches) • Plus que jamais, les applications Web deviennent de plus en plus aussi riches que les applications que vous voyez sur vos postes de travail. Avec MVC, il vous donne la possibilité d'intégrer de telles boîtes à outils (telles que jQuery) avec plus de facilité et de transparence que dans les formulaires Web.
• Optimisation pour les moteurs de recherche (SEO) Convivial / sans état • Les URL sont plus conviviales pour les moteurs de recherche (c.-à-d. Mywebapplication.com/users/ 1 - récupère l'utilisateur avec un ID de 1 vs mywebapplication / users / getuser.aspx (identifiant passé en session)). De même, puisque MVC est sans état, cela supprime le casse-tête des utilisateurs qui génèrent plusieurs navigateurs Web à partir de la même fenêtre (collisions de session). Dans le même esprit, MVC adhère au protocole Web sans état plutôt que de se «battre» contre lui.
• Fonctionne bien avec les développeurs qui ont besoin d'un niveau de contrôle élevé. • De nombreux contrôles des formulaires Web ASP.NET génèrent automatiquement une grande partie du code HTML brut que vous voyez lorsqu'une page est rendue. Cela peut causer des maux de tête aux développeurs. Avec MVC, il se prête mieux à avoir un contrôle complet sur ce qui est rendu et il n'y a pas de surprises. Ce qui est encore plus important, c'est que les formulaires HTML sont généralement beaucoup plus petits que les formulaires Web, ce qui peut équivaloir à une amélioration des performances - quelque chose à considérer sérieusement.
• Développement piloté par les tests (TDD) • Avec MVC, vous pouvez créer plus facilement des tests pour le côté Web des objets. Une couche supplémentaire de tests fournira une autre couche de défense contre un comportement inattendu.

L'authentification, l'autorisation, la configuration, la compilation et le déploiement sont toutes des fonctionnalités partagées entre les deux frameworks Web.

Quiconque est assez vieux pour se souvenir de l'ASP classique se souviendra du cauchemar d'ouvrir une page avec du code mélangé avec du html et du javascript - même la plus petite page était difficile de comprendre ce qu'elle faisait. Je peux me tromper, et j'espère que je le suis, mais MVC a l'air de revenir à ces mauvais vieux jours.

Lorsque ASP.Net est arrivé, il a été salué comme le sauveur, séparant le code du contenu et nous permettant de demander aux concepteurs Web de créer le html et aux codeurs de travailler sur le code derrière. Si nous ne voulions pas utiliser ViewState, nous l'avons désactivé. Si nous ne voulions pas utiliser de code derrière pour une raison quelconque, nous pourrions placer notre code dans le html, tout comme ASP classique. Si nous ne voulions pas utiliser PostBack, nous avons redirigé vers une autre page pour traitement. Si nous ne voulions pas utiliser les contrôles ASP.Net, nous avons utilisé des contrôles html standard. Nous pourrions même interroger l'objet Response si nous ne voulions pas utiliser ASP.Net runat = "server" sur nos contrôles.

Maintenant, quelqu'un dans sa grande sagesse (probablement quelqu'un qui n'a jamais programmé l'ASP classique) a décidé qu'il était temps de revenir à l'époque du mélange de code et de contenu et de l'appeler «séparation des préoccupations». Bien sûr, vous pouvez créer un code HTML plus propre, mais vous pouvez le faire avec un ASP classique. Dire "vous ne programmez pas correctement si vous avez trop de code dans votre vue" revient à dire "si vous avez écrit du code bien structuré et commenté dans ASP classique, il est bien plus propre et meilleur que ASP.NET"

Si je voulais revenir au mélange de code avec du contenu, je voudrais développer en utilisant PHP qui a un environnement beaucoup plus mature pour ce type de développement. S'il y a tant de problèmes avec ASP.NET, pourquoi ne pas résoudre ces problèmes?

Enfin, le nouveau moteur Razor signifie qu'il est encore plus difficile de faire la distinction entre html et code. Au moins, nous pourrions rechercher des balises d'ouverture et de fermeture, c'est-à-dire <% et%> dans ASP, mais maintenant la seule indication sera le symbole @.

Il est peut-être temps de passer à PHP et d'attendre encore 10 ans que quelqu'un sépare à nouveau le code du contenu.

Si vous travaillez avec d'autres développeurs, tels que PHP ou JSP (et je devine des rails) - vous allez avoir beaucoup plus de facilité à convertir ou à collaborer sur des pages parce que vous n'aurez pas tous ces ASP.NET `` méchants '' événements et contrôles partout.

Le problème avec MVC est que même pour les "experts", cela prend beaucoup de temps précieux et demande beaucoup d'efforts. Les entreprises sont guidées par le principe de base «Solution rapide qui fonctionne», quelle que soit la technologie sous-jacente. WebForms est une technologie RAD qui permet d'économiser du temps et de l'argent. Tout ce qui demande plus de temps n'est pas acceptable par les entreprises.

1. AJAX correct, par exemple JSONResults pas de non-sens de publication de page partielle.
2. pas de vue +1
3. Pas de changement de nom des ID HTML.
4. HTML propre = pas de ballonnement et avoir une bonne chance de rendre des pages XHTML ou conformes aux normes.
5. Plus de javascript AXD généré.

Le plus grand avantage pour moi serait la séparation nette entre vos couches Modèle, Vue et Contrôleur. Cela aide à promouvoir une bonne conception dès le départ.

Je n'ai vu AUCUN avantage de MVC sur ASP.Net. Il y a 10 ans, Microsoft a proposé UIP (User Interface Process) comme réponse à MVC. C'était un flop. Nous avons fait un grand projet (4 développeurs, 2 designers, 1 testeur) avec UIP à l'époque et c'était un cauchemar.

Ne vous contentez pas de prendre le train en marche pour le plaisir de Hype. Tous les avantages énumérés ci-dessus sont déjà disponibles dans Asp.Net (avec des modifications plus intéressantes [ Nouvelles fonctionnalités dans Asp.Net 4 ] dans Asp.Net 4).

Si votre équipe de développement ou une seule famille de développeurs avec Asp.Net, respectez-la et fabriquez rapidement de beaux produits pour satisfaire vos clients (qui payent vos heures de travail). MVC va consommer votre temps précieux et produire les mêmes résultats qu'Asp.Net :-)

Francis Shanahan,

1. Pourquoi appelez-vous la publication partielle comme «absurde»? C'est la fonctionnalité principale d'Ajax et a été très bien utilisée dans le framework Atlas et de merveilleux contrôles tiers comme Telerik

2. Je suis d'accord avec votre point de vue concernant l'état de la vue. Mais si les développeurs prennent soin de désactiver viewstate, cela peut réduire considérablement la taille du HTML qui est rendu, ainsi la page devient plus légère.

3. Seuls les contrôles HTML Server sont renommés dans le modèle de formulaire Web ASP.NET et non les contrôles html purs. Quoi qu'il en soit, pourquoi êtes-vous si inquiet si le changement de nom est fait? Je sais que vous voulez gérer de nombreux événements javascript côté client, mais si vous concevez vos pages Web intelligemment, vous pouvez certainement obtenir tous les identifiants que vous voulez

4. Même les formulaires Web ASP.NET répondent aux normes XHTML et je ne vois aucun gonflement. Ce n'est pas une justification de la raison pour laquelle nous avons besoin d'un modèle MVC

5. Encore une fois, pourquoi êtes-vous dérangé par AXD Javascript? Pourquoi ça te fait mal? Ce n'est pas encore une justification valable

Jusqu'à présent, je suis fan de développement d'applications à l'aide de formulaires Web ASP.NET classiques. Par exemple: si vous souhaitez lier une liste déroulante ou une grille, vous avez besoin d'un maximum de 30 minutes et pas plus de 20 lignes de code (minimum bien sûr). Mais dans le cas de MVC, parlez aux développeurs de la douleur.

Le plus gros inconvénient de MVC est que nous retournons à l'époque de l'ASP. Rappelez-vous le code spaghetti de mélanger le code serveur et HTML ??? Oh mon dieu, essayez de lire une page aspx MVC mélangée avec du javascript, du HTML, du JQuery, du CSS, des balises Server et que sais-je encore .... N'importe quel organisme peut répondre à cette question?

Les formulaires Web bénéficient également d'une plus grande maturité et du soutien de fournisseurs de contrôle tiers tels que Telerik.

Dans les formulaires Web, vous pouvez également rendre le HTML presque entier à la main, à l'exception de quelques balises telles que viewstate, eventvalidation et autres, qui peuvent être supprimées avec PageAdapters. Personne ne vous oblige à utiliser GridView ou un autre contrôle côté serveur qui a une mauvaise sortie de rendu HTML.

Je dirais que le plus gros avantage de MVC est la VITESSE!

Vient ensuite la séparation forcée des préoccupations. Mais cela ne vous interdit pas de mettre toute la logique BL et DAL dans Controller / Action! C'est juste une séparation de vue, qui peut également être effectuée dans les formulaires Web (modèle MVP par exemple). Beaucoup de choses que les gens mentionnent pour mvc peuvent être faites dans les formulaires Web, mais avec un effort supplémentaire.
La principale différence est que la demande vient au contrôleur, pas à la vue, et ces deux couches sont séparées, non connectées via une classe partielle comme dans les formulaires Web (aspx + code derrière)

Mes 2 cents:

• Les formulaires ASP.net sont parfaits pour le développement rapide d'applications et pour ajouter rapidement de la valeur commerciale. Je l'utilise toujours pour la plupart des applications intranet.
• MVC est idéal pour l'optimisation des moteurs de recherche car vous contrôlez l'URL et le HTML dans une plus grande mesure
• MVC produit généralement une page beaucoup plus légère - pas de vue et HTML plus propre = temps de chargement rapides
• MVC met facilement en cache des parties de la page. -MVC est amusant à écrire: - avis personnel ;-)

MVC vous permet d'avoir plus d'un formulaire sur une page, une petite fonctionnalité que je connais mais c'est pratique!

Je pense également que le modèle MVC facilite la maintenance du code, en particulier. lorsque vous le revisitez après quelques mois.

Contrôleur MVC:

    [HttpGet]
    public ActionResult DetailList(ImportDetailSearchModel model)
    {
        Data.ImportDataAccess ida = new Data.ImportDataAccess();
        List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);

        return PartialView("ImportSummaryDetailPartial", data);
    }

Vue MVC:

<table class="sortable">
<thead>
    <tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
    @foreach (Data.ImportDetailData detail in Model)
    {
    <tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
    }
</tbody></table>

Est-ce difficile? Pas de ViewState, pas de cycle de vie de la page BS ... Juste du code efficace et pur.

Je peux voir que les deux seuls avantages pour les petits sites sont: 6) Des URL RESTful qui permettent le référencement. 7) Pas d'événements ViewState et PostBack (et de meilleures performances en général)

Les tests pour les petits sites ne sont pas un problème, pas plus que les avantages de conception lorsqu'un site est codé correctement de toute façon, MVC obscurcit à bien des égards et rend les modifications plus difficiles à effectuer. Je continue de décider si ces avantages en valent la peine.

Je peux clairement voir l'avantage de MVC dans les grands sites multi-développeurs.

Le principal avantage que je trouve est qu'il force le projet dans une structure plus testable. Cela peut également être fait assez facilement avec les formulaires Web (modèle MVP), mais nécessite que le développeur comprenne cela, beaucoup ne le font pas.

Les formulaires Web et MVC sont tous deux des outils viables, tous deux excellents dans différents domaines.

J'utilise personnellement des formulaires Web car nous développons principalement des applications B2B / LOB. Mais nous le faisons toujours avec un modèle MVP avec lequel nous pouvons atteindre une couverture de code de 95 +% pour nos tests unitaires. Cela nous permet également d'automatiser les tests sur les propriétés de la valeur de la propriété des contrôles Web est exposée via la vue, par exemple

bool IMyView.IsAdminSectionVisible{
       get{return pnlAdmin.Visible;}
       get{pnlAdmin.Visible=value;}
    }

) Je ne pense pas que ce niveau de test soit aussi facile à atteindre dans MVC, sans polir mon modèle.

Vous ne vous sentez plus mal à l'idée d'utiliser des `` contrôles non post-back '' - et de trouver comment les intégrer dans un environnement asp.net traditionnel.

Cela signifie que les contrôles javascript modernes (gratuits à utiliser) tels que ceci ou cela ou cela peuvent tous être utilisés sans que vous essayiez d'adapter une cheville ronde dans un trou carré.

Les contrôles javascript modernes ainsi que les requêtes JSON peuvent être gérés très facilement à l'aide de MVC. Là, nous pouvons utiliser de nombreux autres mécanismes pour publier des données d'une action à une autre. C'est pourquoi nous préférons MVC aux formulaires Web. Nous pouvons également créer des pages légères.

Mon opinion personnelle est que, le plus gros désavantage à utiliser ASP.Net MVC est que CODE BLOCKSmélangé avec HTML... l'
enfer html pour les développeurs qui le maintiennent ...