Je suis assez nouveau pour la programmation en général (a vraiment commencé il y a seulement 2 1/2 ans) et je suis en train de décider quelle est la meilleure façon d'aborder est une application web que je fais au travail. Un développeur senior au travail me encourage à entrer dans MVC et après un bon 24 heures de verser sur les blogs, le code source et d'autres documents sur le sujet, je commence à comprendre pourquoi je veux l'utiliser.
En même temps, cependant, notre société de les applications existantes sont écrites comme WebForms donc je ne veux pas faire quelque chose d'aussi drastique que l'utilisation du cadre actuel ASP.NET MVC pour faire mon application (serait-il vraiment si drastique si? ).
Ce que je voudrais vraiment savoir si oui ou non il serait pratique ou même possible de faire WebForms mais toujours suivre la philosophie MVC de la séparation des préoccupations. Est-ce que je vraiment être juste d'ajouter une couche inutile à une page .aspx + codebehind déjà compliquée?
Tout le monde dans la blogosphère semble penser qu'ils doivent utiliser une sorte de cadre si elles veulent faire MVC. Qu'est-ce à WebForms qui les empêche de lui faire juste eux-mêmes?
4 Réponses :
Si un senior de votre équipe vous encourage à regarder MVC pour votre application et que vous pensez que c'est un bon coup, alors allez-y (si cette application est autonome surtout).
Vous pouvez également consulter le motif MVVM . C'est ce que beaucoup ont fait avec des formes Web et c'est très similaire au motif MVC. En appliquant le motif MVVM sur WebForms, vous montreriez comment on peut toujours utiliser des formes Web mais obtenir une grande partie de la bonté dans le motif MVC avec ASP.NET MVC. Ce serait une bonne façon de montrer d'autres devs dans l'équipe ce qui peut être fait pour rendre WebForms plus SOC et TESTALTABLE sans abandonner les formes Web.
Voici quelques autres liens sur MVVM:
MVVM est également très populaire dans les applications Silverlight ....
Il y a aussi le MVP modèle également. Voici une implémentation open source pour WebForms . Cette mise en œuvre particulière est utilisée par DotNetNuke 5.3.
Oui, chaque version de MVC est encore plus drastiquement différente des formes Web que la précédente.
Si vous ne voulez vraiment pas utiliser réel MVC, consultez MVP (modèle - Présentateur - Présentateur).
Nous avons utilisé MVP lors d'un emploi précédent, et cela a très bien fonctionné séparant l'interface utilisateur de la couche d'entreprise. Une belle alternative à MVC si vous êtes bloqué dans des formes WebForms.
IMHO, je pense que vous devriez simplement faire le déménagement à MVC.
Voici quelques raisons pour lesquelles je fais la transition:
Alors, revenez à votre question ... Pouvez-vous construire des applications WebForms qui utilisent de nombreuses leçons de MVC. Bien sûr, et si vous allez construire des applications WebForms, je le recommanderais comme une bonne pratique. Pouvez-vous appliquer des cadres pour le rendre plus comme MVC. Bien sûr, mais pourquoi voudriez-vous que vous puissiez utiliser MVC?
D'accord avec tout sauf le premier point. J'entends des formulaires Web 4 sont meilleurs à cela.
Désolé, mais je dois être en désaccord ... WebControls tels que le contrôle du panneau rend certaines hypothèses sur ce qu'ils devraient produire dans diverses conditions. [Par exemple, si je me rappelle correctement, ils émordent un DIP à IE et une table à Firefox ... Cela aurait peut-être changé lorsque je me souviens de l'exécution de cela avec ASP.NET 1.1] En outre, le cadre insiste sur le contrôle de l'ID côté client. tout élément RUNAT = serveur. Selon l'application, ceux-ci peuvent ne pas être des problèmes et je peux être plus puissant que la plupart de ma sortie HTML.
Vous avez manqué le point le plus important de mon point de vue. Avec MVC, votre état est transféré sous forme de données, non pas en tant que page / états de contrôle. Lorsque vous souhaitez obtenir une entrée utilisateur, vous n'avez pas à indiquer explicitement que vous souhaitez une zone de texte, une case à cocher ou une liste déroulante, etc. Vous pouvez utiliser des conventions de constructeur d'entrée pour piloter ce qui est rendu à l'utilisateur en fonction de votre modèle. Cela vous permet de découpler les données / processus d'entreprise à partir de l'interface utilisateur.
Peut-être dans les anciennes versions, mais je faisais référence aux modifications apportées pour contrôler les modes de rendu HTML et d'identification client dans ASP.NET 4. Voir Weblogs. asp.net/scotgu/archive/2010/03/30/...
@Necros - Merci d'avoir mentionné qu'à ASP.NET 4, je n'avais pas encore vu cela. [Je dois toujours être en désaccord que WebForms permet de contrôler un meilleur contrôle sur la sortie HTML que MVC, mais il semble que c'est beaucoup mieux que cela.] ------ @RYAN - bien indiqué, c'est un point qui a été manqué dans mes commentaires.
Oui, vous pouvez toujours utiliser des formes Web et appliquer une philosophie MVC. Pour la plupart, les formulaires Web ne vous empêchent pas d'appliquer des principes MVC; Cela peut simplement vous amener dans le mauvais chemin. Si vous êtes toujours un magasin WebForms, essayez d'appliquer certaines des choses suivantes qui se trouvent dans «l'esprit» de MVC. Cela aidera à faire un futur passage de Webforms à MVC moins drastic.
Utilisez le routage. Dans WebForms, vous pouvez mapper itinéraires vers .aspx pages plutôt que contrôleurs pour obtenir de belles URL sans extension. Si vous utilisez .NET 3.5 Vous aurez besoin d'un gestionnaire de route personnalisé. Dans 4.0, le routage est intégré.
Évitez d'utiliser des gestionnaires d'événements dans votre code derrière. Page_load sera assez dans la plupart des cas.
Évitez d'utiliser la visionnement et les contrôles Web pour garder votre balisage propre et maigre. Si vous avez un bouton d'envoi dans votre balisage, écrivez-le comme ceci << code> Type d'entrée = "bouton" plutôt que comme celui-ci: Utilisez jQuery pour la configuration des gestionnaires d'événements, AJAX et la manipulation du côté client.
adopte le concept de menuLodel en associant un objet de menu de vue avec vos pages .aspx.
Si vous avez besoin de webcontrols, utilisez clientIdMode = "statique" pour le contrôle
sur vos identifiants dans le balisage (.NET 4.0)
<% =%> comme que vous voyez dans MVC plutôt que d'utiliser des commandes d'étiquettes et de répéteurs.