8
votes

Asp.net mvc vs asp.net formulaires

Pourquoi envisageriez-vous d'utiliser ASP.NET MVC ou Standard ASP.NET avec des formulaires et des contrôles pour un projet Web? Outre la préférence personnelle, quelles seraient les raisons? Quel type de projets trouvez-vous plus approprié pour MVC et quels projets pour la normale ASP.NET?

Voulez-vous envisager de transférer vos projets actuels sur l'une ou l'autre?


0 commentaires

3 Réponses :


8
votes

WebForms est une abstraction qui masque la mécanique de la bande du développeur. Il permet aux développeurs de bureau de transférer relativement facilement leurs compétences sur le Web. Bien que cela réalise cela en partie, dans des scénarios pratiques, il n'est généralement pas long avant que les pauses d'abstraction et que l'on doive mettre des solutions de contournement désordonnées. Les tests d'unités sont difficiles, car la logique pour la manipulation des interactions utilisateur est étroitement couplée à l'interface utilisateur. Le HTML produit par une application WebForms typique est loin d'être optimal. Il est typiquement gonflé, difficile à lire et contient beaucoup de contenu qui est présent uniquement pour permettre à l'abstraction de travailler, par ex. Viewstate, qui est une énorme blob d'informations pour aider l'abstraction à donner l'illusion de l'état au développeur, même si le Web est un support apatride.

MVC, cependant, embrasse la mécanique de la bande. Les opérations fondamentales qui se déroulent dans une demande Web et une réponse sont présentées au développeur comme des abstractions simples. MVC a une séparation claire des préoccupations. Le modèle représente simplement les objets commerciaux ou entités avec lesquels le système est concerné, avec des méthodes de récupération et de stockage des instances de ces objets. Le contrôleur prend une demande sur le Web, effectue des opérations sur le modèle, puis remet le modèle à la vue. La vue est purement un rendu, pour présenter le modèle à l'utilisateur et exposant les éléments d'interface permettant à l'utilisateur de formuler la demande suivante à passer à un contrôleur. Cette séparation des préoccupations permet des tests d'unités relativement faciles. Le développeur a une commande complète sur le HTML produit et il n'est pas nécessaire que d'autres artefacts soient présents (par exemple Viewstate).

Je préfère MVC. Pour de rares occasions, il peut être utile d'utiliser des formes WebForms, par ex. Un prototype ou une démo rapide, mais sinon je recommanderais toujours l'utilisation de MVC.

En ce qui concerne le transfert d'un projet de Webforms à MVC, ceci est évidemment très subjectif et dépendant de la demande elle-même, ainsi que des contraintes budgétaires, mais en général, je pense que c'est une étape dans la bonne direction.


0 commentaires

1
votes

Vous pouvez trouver de nombreuses différences, avantages à propos de l'ASP.NET MVC sur l'ASP.NET normal

applications. Si ce n'est pas gentiment visitez la pile sur conversation.

Le plus grand avantage d'utiliser ASP.NET MVC VS Formulaires Web

La raison du choix du concept MVC pour votre demande varie de nombreuses choses

  1. Quoi pour votre demande? Soit une sorte de forum, d'outil de rapport ou de site Web intranet

  2. si vous voulez suivre le modèle de décès ou non?

    Si oui, alors si cela va être MVC ou tout autre ??

  3. si vous avez besoin de modularité pour des améliorations futures?

  4. si vous avez besoin de contrôle total sur votre code?

  5. Un meilleur support sur la partie de test du point de vue du développeur devrait être là ou non?

    Si vous êtes sûr de ces choses, vous pouvez alors déplacer votre modèle Appln au modèle de cadre MVC.

    Autre Sage Il est préférable de continuer avec ASP.NET web.apps, car il inclut toutes les dernières

    caractéristique de l'industrie actuelle.


2 commentaires

Je n'obtiens pas le point 4, que vous ayez besoin d'un contrôle total sur votre code? Je n'ai jamais remarqué un manque de contrôle avec le code ASP.NET.


Contrôle - Architecture de votre code par vous-même. il n'y aura pas de blocs de code générés automatiquement comme dans les applications ASP.NET normales



13
votes

Les formulaires Web ASP.NET et MVC sont deux cadres Web développés par Microsoft - ils sont tous deux de bons choix. Aucun des cadres Web ne doit être remplacé par l'autre et il n'y a pas de prévoir «fusionné» dans un seul cadre. Le soutien et le développement continu sont effectués en parallèle par Microsoft et non plus «partir».

Chacun de ces cadres Web offre des avantages / inconvénients - dont certains doivent être pris en compte lors de l'élaboration d'une application Web. Une application Web peut être développée à l'aide de la technologie - elle pourrait faciliter la mise en place d'une application particulière de sélectionner une technologie par rapport à l'autre et inversement.

ASP.NET Web Formulaires:

  • Développement Supports State • Donne à l'illusion qu'une application Web est consciente de ce que l'utilisateur a fait, similaire aux applications Windows. C'est à dire. Donne une fonctionnalité de «magicien» un peu plus facile à mettre en œuvre. Les formulaires Web font un excellent travail pour cacher une grande partie de cette complexité du développeur.
  • Développement d'applications rapide (RAD) • La possibilité de «sauter» et de commencer à livrer des formulaires Web. Ceci est contesté par une partie de la communauté MVC, mais poussée par Microsoft. En fin de compte, cela revient au niveau d'expertise du développeur et de ce qu'ils sont à l'aise. Le modèle de formulaires Web a probablement moins d'une courbe d'apprentissage à des développeurs moins expérimentés.
  • Boîte à outils de contrôle plus grande • ASP.NET Web Forms propose une boîte à outils beaucoup plus grande et plus robuste (contrôles Web), tandis que MVC offre un ensemble de contrôle plus primitif comptant davantage sur de riches commandes côté client via JQuery (JavaScript).
  • mature • Cela fait partie depuis 2002 et il y a une abondance d'informations concernant des questions, des problèmes, etc. propose davantage de contrôle tiers - doit prendre en compte vos kits à outils existants.

    asp.net mvc:

    • séparation des préoccupations (SOC) • À partir d'un point de vue technique, l'organisation du code au sein de MVC est très propre, organisée et granuleuse, ce qui facilite la tâche d'une application Web à l'échelle en termes de fonctionnalité. Favorise l'excellent design d'un point de vue du développement.
    • Intégration plus facile avec les outils latéraux du client (outils d'interface utilisateur riches) • Plus que jamais, les applications Web deviennent de plus en plus riche que les applications que vous voyez sur vos ordinateurs de bureau. Avec MVC, cela vous donne la possibilité d'intégrer avec de telles outils à outils (telles que JQuery) avec une plus grande facilité et plus transparente que celle des formes Web.
    • Optimisation des moteurs de recherche (SEO) convivial / apatride • Les URL sont plus amicales pour les moteurs de recherche (c'est-à-dire mywebApplication.com/users/ 1 - Récupérer l'utilisateur avec un identifiant de 1 vs mywebApplication / users / getuser.aspx (ID passée dans la session)). De même, étant donné que MVC est apatride, cela supprime le mal de tête des utilisateurs qui espèrent plusieurs navigateurs Web de la même fenêtre (collisions de session). Le long de ces mêmes lignes, MVC adhère au protocole Web apatrides plutôt que de «combattre» contre elle.
    • fonctionne bien avec les développeurs qui ont besoin de haut degré de contrôle • Les 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 pour les développeurs. Avec MVC, vous avez un contrôle complet sur ce qui est rendu et il n'y a pas de surprises. Encore plus important, est que les formes HTML sont généralement beaucoup plus petites que les formes Web pouvant assimiler à une performance Boost - quelque chose à considérer sérieusement.
    • Développement axé sur les tests (TDD) • Avec MVC, vous pouvez plus facilement créer des tests pour le côté Web des choses. Une couche supplémentaire de tests fournira encore une autre couche de défense contre les comportements inattendus.

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


0 commentaires