ASP.NET MVC - Comment l'expliquer?

Question

J'essaie d'enseigner ASP.NET MVC aux étudiants (étudiants de premier cycle) qui ont étudié ASP.NET pour les 8 dernières semaines (je sais que cela ne semble pas beaucoup de temps, mais la classe est de 4 heures par jour, 5 jours par semaine avec Labs, Quiz, Examens et Wrestles).

Je n'ai pas eu la question encore ... mais je sais qu'il arrive ...

Quand dois-je utiliser MVC au lieu d'ASP ??

Je n'ai aucune expérience réelle avec ASP MVC et je ne trouve aucune réponse claire sur le Web. Des arguments tels que "... le web est sans état et ASP MVC est un match plus proche etc etc" ne signifient pas grand chose pour eux. Ils commencent à remarquer que ASP a beaucoup de contrôles qui semblent simplifier leur balisage par rapport à MVC. J'essaie de donner un tour honnête, et tous les commentaires seraient très appréciés! TIA

Answer 1

L'apatridie est un bon mot à expliquer comme déjà souligné par les membres. En dehors de cela, posez les questions suivantes aux étudiants?

S'ils doivent faire ce qui suit avec ASP.NET (pas de MVC), à quel point sera-t-il facile?

1. Testez vos vues
2. objets Mock Http.
3. réduction de Viewstate (par la conception) (
4. de ViewEngine léger de remplacement pour .aspx.
5. de séparation approfondie des préoccupations.
6. HTML propre
7. etc etc ..

maintenant expliquer asp .net mvc dans le contexte ci-dessus.Il peut y avoir plus à Atleast Je pense qu'ils vont avoir le point, pensé que cela peut ne pas être applicable à tous les projets, mais quel est le mal si nous ne gagnons que de cela

Answer 2

Pour moi, l'approche MVC est un paradigme très différent de l'API ASP Forms. Je pense que l'idée d'être «apatride» est un bon moyen d'expliquer un sujet très vaste en un mot.

L'un des principaux avantages que j'ai vu est que le cadre MVC donne beaucoup de contrôle sur la conception et la sortie de votre page. Pour les petits projets, cela peut ne pas être le meilleur usage, mais pour les grands projets, il évolue très bien parce que vous pouvez faire différents choix architecturaux que (personnellement) je trouve meilleurs, comme la façon dont le framework MVC sépare la logique de la vue. De plus, si vous concevez un site qui a beaucoup de Javascript, le contrôle que vous gagnez sur la sortie dans le framework MVC peut être très utile car vous n'avez pas à vous soucier autant des IDs et des autres balisages peut être rendu, comme vous le faites généralement dans le cadre ASP Forms.

Le framework MVC est vraiment une manière totalement différente de concevoir des sites web. Personnellement, je pense que c'est plus bénéfique pour les grands projets, mais j'ai aussi commencé dans les langages web où MVC était un choix de conception plus populaire pour commencer.

C'est juste mes 2 cents.

Answer 3

Pour quelqu'un avec de l'expérience (et des douleurs) dans Winforms - la plus grande différence n'est plus Viewstate. L'état des contrôles sur le formulaire est conservé sur le client, dans le navigateur et envoyé au serveur pour chaque requête. Si vous utilisez Javascript, il est plus facile d'apporter des modifications du côté du navigateur, tandis que le côté serveur peut facilement voir le formulaire dans son ensemble sans avoir à recréer la liaison des contrôles. Au-delà de toutes les bonnes choses que MVC fournit - séparation de vue/code, testabilité - c'était pour moi le point clé pour passer à MVC.

Answer 4

J'ai toujours pensé que ASP.NET MVC Framework était un mauvais nom puisqu'il s'agit d'un motif de conception.

La question devrait être:

Quand utiliser ASP.NET Framework MVC sur les formulaires Web ASP.NET?

Le développeur Expérience

a) Web Forms ASP.NET tente d'abstraire la nature sans état de HTTP du développeur. L'état des éléments GUI et/ou les données sont stockés dans Viewstate/Session. Tout le monde forme une publication sur elle-même, imitant essentiellement le comportement d'un design piloté par un événement WinForm.

b) Les éléments de l'interface graphique HTML sont en outre analysés par des contrôles qui peuvent être réutilisés, achetés à des fournisseurs tiers. Cela permet aux développeurs de coller une application HTML ensemble sans trop de connaissances JavaScript et HTML/HTTP. Fondamentalement similaire à la façon dont vous développeriez VB/WinForms

c) Vous pouvez faire du bon travail en implémentant le modèle MVC/MVP dans les formulaires Web ASP.NET. Regardez la fabrique de logiciels Web de Patterns and Practices pour voir comment ils l'ont fait.

d) En utilisant WebForms, vous modifiez généralement le HTML (View) en fonction des commentaires des utilisateurs sur le serveur. La plupart des événements (l'utilisateur clique sur un bouton, modifie un champ) sont traités sur le serveur dans une boucle de publication continue exécutant ce que l'on appelle le cycle de vie de la page ASP.NET.

VS

vue contrôlée

Browser (ne sais pas quoi d'autre pour l'appeler). Toutes les modifications apportées au code HTML en fonction de la saisie par l'utilisateur sont gérées dans le navigateur. Vous allez manipuler le DOM avec Javascript.

Note: Je basant cela sur le fait que ASP.NET MVC est très probablement tirée par HTML de base + Ajax

Comment je choisirais personnellement entre eux (jamais avoir utilisé MVC, en train de lire à ce sujet)

1) Si je devais construire un frontal sans état pur en utilisant Ajax, Jquery, EXT JS bibliothèques ASP.NET MVC semblerait le meilleur ajustement. Bien que vous puissiez le créer dans des formulaires Web ASP.NET, cela semble inutile puisque vous ne profitez pas du modèle de publication et des contrôles serveur.

2) Si on me demandait de créer une nouvelle application Web de base, je m'en tiendrais aux Webforms ASP.NET puisque je la connais déjà et que je connais l'ensemble de la page lifecylce.

3) Si on me demandait de construire un site Web 2.0 (déteste ce terme) pour avoir une prochaine expérience utilisateur gen, j'irais probablement avec ASP.NET MVC, et utiliser les contrôles client JQuery/ASP.NET Ajax.

4) De nombreuses entreprises ont mis en place un ensemble solide de contrôles WebForm à utiliser. Il serait coûteux de les reconstruire tous de manière purement apaxiale et sans état.

Answer 5

À part toutes les autres excellentes réponses déjà listées. Webforms est une abstraction absente loin du HTML. Lorsque vous voulez un tableau de données html, vous mettez un contrôle "gridview" sur une page - ce que vous finissez avec est "gridview" html, et très probablement pas exactement ce que vous étiez après. La chaussure s'adapte 90% du temps, mais beaucoup de temps, surtout quand les choses vont au-delà d'un site de base que les contrôles ne correspondent pas. L'utilisation de Webforms signifie souvent que vous n'avez pas le contrôle total sur la sortie finale rendue au navigateur.

Vous pouvez bien sûr étendre ou écrire votre propre contrôle de grille. Mais ne préféreriez-vous pas simplement écrire le code HTML que vous voulez à la place? D'après mon expérience, les projets deviennent de plus en plus complexes et l'interface utilisateur devient de plus en plus compliquée, ce qui vous oblige à vous battre de plus en plus souvent contre les Webforms.

Answer 6

http://www.emadibrahim.com/2008/09/07/deciding-between-aspnet-mvc-and-webforms/