Actuellement, je travaille sur le projet Web intégré à l'aide de formulaires Web ASP.NET. Nous voulons commencer à construire de nouvelles pages à l'aide du cadre MVC.
semble être en cours d'exécution MVC et web formulaires côte à côte est faisable http://weblogs.asp.net/rajbk/archive/2010/05/11/Running-asp-net-webForms-and-asp-net-mvc -Side par le côté.aspx
Je suis curieux s'il y a des problèmes ou des gotchas que je dois planifier.
Je cours sur ASP.NET 4.0 et prévoyez d'utiliser MVC3.
5 Réponses :
Le seul gotcha, je peux penser à être tenté de réutiliser le code WebForms existant dans la partie MVC et de vous retrouver avec de jeux de données dans votre action de contrôleur ou (mai Dieu nous interdit) dans votre point de vue :-) Un autre gotcha avec réutilisation de ce code est que vous devriez faire très attention à ne pas vous retrouver avec runat = "serveur" Stuff à vos vues MVC. Je garderais les deux parties aussi couplées que possible. Et à cause de cela, je ne les mélangerais pas dans le même projet: -)
En plus de Ce que Darin a dit , essayez de ne pas utiliser le moteur de vue WebForms si vous pouvez l'aider et créer des itinéraires d'URL appropriés afin que les pages qui doivent être traitées par des formes Web sont toujours gérées par WebForms.
@bzlm: Merci d'avoir ajouté un lien direct.
Je suppose que cela dépend de quelle interaction il y aura entre les formes Web et les parties MVC du site. Si les deux utilisent les mêmes back-end et même session de sécurité, vous devriez être correct. Vous pouvez rencontrer des problèmes si un formulaire Web et une action MVC doivent coopérer. Comme je le disais, tout dépend vraiment de ce que l'interaction sera. S'ils fonctionnent côte à côte mais se laissant seul, alors vous devriez aller bien.
Un problème qui pourrait se produire est le changement de pensée nécessaire pour passer de Webforms à MVC et vice-versa, bien que l'expérience et la pratique vous apprendront ici.
J'ai exécuté WebForms et MVC ensemble pour une application interne ici. Il a démarré comme une application WebForms et je l'ai migré en MVC2 (puis 3) avec plusieurs morceaux travaillant toujours avec Webforms toujours.
Comme Darin dit, le principal gotcha va être avec des modèles. Si vous utilisez le moteur de vue WebForms, vous devez créer 2 couches de pages maîtres. Le code WebForms (tel que le gestionnaire de script) ne fonctionne pas sur les pages MVC et le code MVC ne fonctionne pas sous les pages WebForms.
Mes pages maîtres sont configurées avec une page maître globale qui ne contient aucun code MVC ou WebForms. Il n'a que CSS, Global JavaScript et la mise en page principale. J'ai ensuite une page maître MVC et une page de maître WebForms, les deux ont des directives pour utiliser la page Master globale en tant que pages maîtres. Ensuite, chaque page WebForms utilise la page Sous-maître WebForms et le MVC utilise la page sous-maître MVC.
Si vous devez mettre du code dans la page Master globale, vous pouvez détecter si la sous-page est une page WebForms ou MVC en testant si Cependant, si vous décidez d'aller avec le moteur de vue du rasoir (que je recommande pour MVC, c'est tellement meilleur) il devient plus difficile. Vous devez effectuer des travaux supplémentaires sur ce que j'ai déjà mentionné précédemment. Ce blog post devrait aider à ce sujet. page est System.web.mvc.viewpage . Si c'est true , il s'agit d'une page MVC, sinon il s'agit d'une page WebForms.
Merci. Cela me conduise également à d'autres messages: eworldui.net/blog/post/2008/05/09/... et EWORLDUI.NET/BLOG/POST/2011/01/07/...
Je suggère de garder les deux applications séparées et de leur donner différents sous-domaines, vous pourriez peut-être les garder sur le même sous-domaine en utilisant un répertoire virtuel, mais je n'ai pas aimé cette approche.
Vous pouvez utiliser un seul cookie pour valider sur les deux applications en partageant la validationkey et la déchiffrementkey.
De cette façon, vos bases de code ne se mélangent pas et vous ne combattez pas de problèmes de fichier de configuration.
J'ai posté un Description plus longue de cette approche.