Plus gros avantage à utiliser ASP.Net MVC vs formulaires Web
Quels sont certains des avantages d'utiliser l'un par rapport à l'autre?
Les principaux avantages de ASP.net MVC sont les suivants:
Active le contrôle total sur le code HTML rendu.
Fournit une séparation nette des préoccupations (SoC).
Intégration facile avec les frameworks JavaScript.
Suivre la conception de la nature sans état du Web.
URL de repos permettant le référencement.
Aucun événement ViewState et PostBack
Les principaux avantages de ASP.net Web Form sont les suivants:
Il fournit RAD développement
Modèle de développement facile pour les développeurs issus du développement Winform.
ASP.NET Web Forms et MVC sont deux infrastructures Web développées par Microsoft. Ce sont de bons choix. Aucun des cadres Web ne doit être remplacé par un autre, pas plus qu'il n'est prévu de les fusionner en un seul cadre. Le support et le développement continus sont effectués en parallèle par Microsoft et aucun ne "partira".
Chacun de ces cadres 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 technologie. Cela pourrait faciliter le développement d’une application particulière en sélectionnant une technologie plutôt que l’autre et inversement.
Formulaires Web ASP.NET:
- Etat de prise en charge du développement • Donne l'illusion qu'une application Web est au courant de ce que l'utilisateur a fait, comme les applications Windows. C'est à dire. Facilite la mise en œuvre de la fonctionnalité 'assistant'. Les formulaires Web dissimulent beaucoup de cette complexité au développeur.
- Développement rapide d'applications (RAD) • La possibilité d'intervenir et de commencer à distribuer 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 comporte probablement moins de courbe d'apprentissage que les développeurs moins expérimentés.
- Boîte à outils de contrôles plus grande • ASP.NET Web Forms offre une boîte à outils (contrôles Web) beaucoup plus grande et plus robuste, tandis que MVC offre un jeu de contrôles plus primitif reposant davantage sur des contrôles riches côté client via jQuery (Javascript).
- Mature • Cela existe depuis 2002 et les informations concernant les questions, les problèmes, etc. sont abondantes. Offre davantage de contrôle par des tiers - vous devez tenir compte de vos outils existants.
ASP.NET MVC:
- Séparation des préoccupations (SoC) • D'un point de vue technique, l'organisation du code dans MVC est très propre, organisée et granulaire, ce qui facilite (espérons-le) le fait qu'une application Web puisse évoluer en termes de fonctionnalités. Favorise un excellent design 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 riches, tout comme les applications que vous voyez sur vos ordinateurs de bureau. Avec MVC, cela vous donne la possibilité de vous intégrer à de tels kits d'outils (tels que jQuery) avec une plus grande facilité et plus de transparence que dans Web Forms.
- Optimisation pour les moteurs de recherche (SEO) Friendly/Stateless • Les URL sont plus conviviales pour les moteurs de recherche (c.-à-d. Mywebapplication.com/users/ 1 - récupère un utilisateur ayant un ID égal à 1 vs mywebapplication/users/getuser.aspx ( id passé en session)). De même, MVC étant sans état, cela supprime les maux de 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 ordre d'idées, MVC adhère au protocole Web sans état au lieu de "lutter contre".
- fonctionne bien avec les développeurs nécessitant un contrôle important • De nombreux contrôles dans les formulaires Web ASP.NET génèrent automatiquement une grande partie du code HTML brut affiché lors du rendu d'une page. Cela peut causer des maux de tête pour les développeurs. Avec MVC, il se prête mieux pour avoir un contrôle total sur ce qui est rendu et il n’ya 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 être synonyme d’amélioration des performances - un élément à prendre au sérieux.
- Développement piloté par les tests (TDD) • Avec MVC, vous pouvez créer plus facilement des tests pour le Web. Une couche supplémentaire de tests fournira une couche de défense supplémentaire contre les comportements inattendus.
L'authentification, l'autorisation, la configuration, la compilation et le déploiement sont toutes des fonctionnalités partagées entre les deux infrastructures Web.
Toute personne assez âgée pour se souvenir de classic ASP se souviendra du cauchemar consistant à ouvrir une page avec du code mélangé avec du HTML et du javascript - même la plus petite page était difficile à comprendre ce qu'elle était en train de faire. Je peux me tromper et j'espère bien, mais MVC semble remonter à ces mauvais 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 code HTML et aux programmeurs de travailler sur le code. Si nous ne voulions pas utiliser ViewState, nous l'avons désactivé. Si nous ne voulions pas utiliser le code derrière pour une raison quelconque, nous pourrions placer notre code dans le code HTML comme un ASP classique. Si nous ne voulions pas utiliser PostBack, nous avons été redirigés vers une autre page pour traitement. Si nous ne voulions pas utiliser les contrôles ASP.Net, nous utilisions 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.
Désormais, quelqu'un dans leur 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 avec du contenu et de l'appeler "séparation des problèmes". Bien sûr, vous pouvez créer du HTML plus propre, mais vous pouvez le faire avec ASP classique. Dire "vous ne programmez pas correctement si vous avez trop de code dans votre vue" revient à dire "si vous écrivez du code bien structuré et commenté dans classic ASP, il est beaucoup plus propre et meilleur qu'ASP.NET"
Si je voulais recommencer à mélanger du code avec du contenu, je développerais avec PHP, qui offre 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 les résoudre?
Enfin, le nouveau moteur Razor signifie qu’il est encore plus difficile de distinguer le code HTML et le code HTML. Au moins, nous pourrions rechercher des balises d’ouverture et de fermeture, par exemple <% et%> dans ASP, mais la seule indication à présent 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 Rails), vous aurez beaucoup plus de facilité à convertir ou à collaborer sur des pages car vous n'aurez pas toutes ces informations. 'méchants' événements ASP.NET et contrôles partout.
Le problème avec MVC est que même pour les "experts", cela prend beaucoup de temps et demande beaucoup d’efforts. Les entreprises sont guidées par le principe de base "Une solution rapide qui fonctionne", quelle que soit la technologie utilisée. WebForms est une technologie RAD qui permet d'économiser du temps et de l'argent. Tout ce qui nécessite plus de temps n’est pas acceptable pour les entreprises.
- AJAX, par exemple JSONResults pas de non-sens partiel de publication de page.
- aucun point de vue +1
- Pas de changement de nom des identifiants HTML.
- HTML propre = pas de problème et capacité de restituer des pages conformes au XHTML ou aux normes.
- Plus de javascript AXD généré.
Je n'ai vu AUCUN avantage de MVC par rapport à ASP.Net. Il y a 10 ans, Microsoft proposait UIP (User Interface Process) comme solution à MVC. C'était un flop. Nous avons réalisé un grand projet (4 développeurs, 2 concepteurs, 1 testeur) avec UIP à l'époque et ce fut un véritable cauchemar.
Ne vous contentez pas de prendre le train en marche pour l'amour de Hype. Tous les avantages énumérés ci-dessus sont déjà disponibles dans Asp.Net (avec plus de réglages géniaux [ Nouvelles fonctionnalités de Asp.Net 4 ] dans Asp.Net 4).
Si votre équipe de développement ou une famille de développeurs unique avec Asp.Net n’y adhérez pas et fabriquez rapidement de beaux produits pour satisfaire vos clients (qui paie pour vos heures de travail). MVC consommera votre temps précieux et produira les mêmes résultats que Asp.Net :-)
Pour moi, le plus gros avantage serait la séparation nette entre les couches Modèle, Vue et Contrôleur. Cela aide à promouvoir un bon design dès le départ.
Francis Shanahan,
Pourquoi appelez-vous la publication partielle comme "absurdité"? C’est la caractéristique principale d’Ajax et elle a été très bien utilisée dans le cadre d’Atlas et dans de merveilleux contrôles tiers, tels que Telerik.
Je suis d'accord avec votre point concernant le viewstate. Mais si les développeurs prennent soin de désactiver viewstate, la taille du code HTML qui est rendu peut être considérablement réduite, de sorte que la page devient légère.
Seuls les contrôles de serveur HTML sont renommés dans le modèle de formulaire Web ASP.NET et non de contrôles html purs. Quoi qu'il en soit, pourquoi êtes-vous si inquiet si le changement de nom est terminé? Je sais que vous souhaitez gérer de nombreux événements javascript côté client, mais si vous concevez intelligemment vos pages Web, vous pouvez certainement obtenir tous les identifiants que vous souhaitez.
Même les formulaires Web ASP.NET sont conformes aux normes XHTML et je ne vois pas de ballonnement. Ce n'est pas une justification de la raison pour laquelle nous avons besoin d'un modèle MVC
Encore une fois, pourquoi êtes-vous dérangé par le langage AXD Javascript? Pourquoi ça te fait mal? Ce n'est pas encore une justification valable
Jusqu'à présent, je suis un partisan du développement d'applications utilisant des formulaires Web ASP.NET classiques. Par exemple: Si vous souhaitez lier une liste déroulante ou une vue en grille, vous avez besoin d’un maximum de 30 minutes et d’un maximum de 20 lignes de code (minimum bien sûr). Mais dans le cas de MVC, demandez aux développeurs à quel point c'est douloureux.
Le plus gros inconvénient de MVC est que nous remontons à 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 à des balises javascript, HTML, JQuery, CSS, Server et quoi encore ... Tout organisme peut répondre à cette question?
Les formulaires Web gagnent également en maturité et en prise en charge avec des fournisseurs de contrôle tiers tels que Telerik.
Dans les formulaires Web, vous pouvez également restituer à la main presque tout le code HTML, à l'exception de quelques balises telles que viewstate, eventvalidation, etc., qui peuvent être supprimées à l'aide de PageAdapters. Personne ne vous oblige à utiliser GridView ou un autre contrôle côté serveur ayant une sortie de rendu HTML incorrecte.
Je dirais que le plus grand avantage de MVC est la vitesse!
Suivant est 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! Il ne s'agit que d'une séparation des vues, ce qui peut également être fait dans les formulaires Web (modèle MVP par exemple). Un grand nombre de choses que les gens mentionnent pour MVC peuvent être effectuées dans des formulaires Web, mais moyennant des efforts supplémentaires.
La principale différence est que la demande est transmise au contrôleur et non à la vue, et que ces deux couches sont séparées et non connectées via une classe partielle, comme dans les formulaires Web (aspx + code derrière).
Mes 2 centimes:
- Les formulaires ASP.net sont parfaits pour le développement rapide d'applications et ajouter rapidement de la valeur commerciale. Je l'utilise encore pour la plupart des applications intranet.
- MVC est idéal pour l'optimisation des moteurs de recherche, car vous contrôlez davantage l'URL et le HTML.
- MVC produit généralement une page beaucoup plus légère - pas de viewstate et HTML plus propre = temps de chargement rapides
- MVC facile à mettre en cache des parties de la page. -MVC est amusant à écrire: - opinion personnelle ;-)
MVC vous permet d'avoir plus d'un formulaire sur une page, une petite fonctionnalité que je connais mais qui est pratique!
Je pense également que le modèle MVC facilite la maintenance du code, en particulier. quand vous 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>
Comment est-ce difficile? Pas de ViewState, pas de BS Cycle de vie d'une page ... Juste du code purement efficace.
Le principal avantage que j’ai trouvé est que cela force le projet à adopter une structure plus testable. Cela peut également être facilement fait avec des formulaires Web (modèle MVP), mais nécessite que le développeur comprenne bien cela, beaucoup ne le font pas.
Les formulaires Web et MVC sont des outils viables, Excel dans différents domaines.
Personnellement, j'utilise 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 plus de 95% pour nos tests unitaires. Cela nous permet également d'automatiser les tests sur les propriétés de la propriété webcontrols. La valeur est exposée à travers 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 facilement atteint dans MVC, sans poluer mon modèle.
Je peux voir que les deux seuls avantages des sites plus petits sont: 6) des URLs reposantes qui permettent le référencement. 7) Aucun événement ViewState et PostBack (et de meilleures performances en général)
Tester les sites de petite taille n’est pas un problème, pas plus que les avantages de la conception d’un site correctement codé, mais MVC obscurcit et rend les modifications plus difficiles à effectuer. Je suis encore en train 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.
Vous ne vous sentez plus mal d'utiliser des 'contrôles non post-back' - et de savoir comment les insérer dans un environnement asp.net traditionnel.
Cela signifie que les contrôles javascript modernes (gratuits) tels que this ou this ou this peuvent tous être utilisés sans que cela ne tienne dans le but de faire tenir une cheville ronde dans une sensation de trou carré.
Mon opinion personnelle est que, le plus gros inconvénient d'utiliser ASP.Net MVC est que CODE BLOCKS est mélangé à HTML...
html hell pour les développeurs qui le maintiennent ...
Les contrôles javascript modernes ainsi que les requêtes JSON peuvent être gérés beaucoup plus facilement avec MVC. Là, nous pouvons utiliser beaucoup d'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 aussi construire des pages légères.