Revenir à ASP.Net Webforms depuis ASP.Net MVC. Recommander des modèles / architectures?

Pour beaucoup d'entre vous, cela ressemblera à une question ridicule, mais je pose la question parce que je n'ai pas ou peu d'expérience avec ASP.Net Webforms - je suis allé directement à ASP.Net MVC.

Je travaille actuellement sur un projet où nous sommes limités à .Net 2.0 et Visual Studio 2005.

J'ai aimé la séparation nette des préoccupations lorsque je travaille avec ASP.Net MVC, et je cherche quelque chose pour rendre les formulaires Web moins insupportables. Existe-t-il des modèles ou des pratiques recommandés pour les personnes qui préfèrent asp.net MVC, mais qui sont bloquées sur .net 2.0 et Visual Studio 2005?

Je recommanderais Model View Presenter (MVP). Nous l'avons utilisé sur une application WebForms récente et cela a augmenté notre testabilité et nous a permis d'imposer la séparation des préoccupations.

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx est un excellent article de Jean Paul Boodhoo sur ce modèle; le téléchargement de code est également bon. Vous pouvez cependant constater que vous n'avez pas besoin de DTO et d'interfaces pour les DTO.

Un autre bon article est celui-ci sur codeproject.com: http://www.codeproject.com/KB/architecture/ModelViewPresenter.aspx

Edit: il existe également un framework appelé WebForms MVP mais je n'en sais pas grand-chose.

Je vous recommande de comprendre le cycle de vie des pages de .net 2.0

Ces vidéos peuvent valoir la peine d'être visionnées, bien que toutes ne soient pas gratuites, mais au moins ce sera un bon début pour vous.

Comme vous l'avez peut-être découvert maintenant, vous devrez désapprendre deux ou trois choses que vous avez apprises avec ASP.NET MVC (btw - la même chose se produit lorsqu'une personne ASP.NET se précipite pour apprendre ASP.NET MVC). Vous pouvez toujours implémenter le modèle MVC dans ASP.NET mais la séparation de la vue et du modèle est très floue dans ASP.NET en raison de l'architecture d'événement / de publication de page.

À mon avis, la plupart de vos nouveaux apprentissages seront liés au cycle de vie des pages et aux événements et contrôles. Les interactions habituelles Session, Cache, ViewState et DB restent les mêmes.

HTH ...

Checkout Front Controller pattern et Implementing Front Controller in Asp.Net. Ne faites ces choses que si votre projet va être de bonne taille. Faire cela pour un petit projet ne justifiera pas le retour sur investissement.

Dans un petit projet, vous pouvez essayer de définir des lignes directrices. Par exemple - Aucune logique métier, aucune utilisation de session, etc. dans le code derrière.

Voyez ce qui vous convient le mieux. En tout cas retenez la tentation de faire plus que de l'ingénierie.

À l'époque sombre de .NET 1.1, j'ai créé (je suppose que tout le monde) une sorte de système MVC pour une application qui allait comme ça.

Une page a été faite pour être une sorte de «faux» maître. Cela avait de la plomberie pour afficher les menus, les scripts, les styles, etc.

Les «vues» étaient des commandes utilisateur individuelles.

Il y avait un tableau avec des informations sur chaque vue. Par exemple, «Produit» se chargerait ~/Controls/Product.ascxdans un espace réservé. La table avait également un champ qui contenait le nom de type de la classe de modèle (comme si). Chaque modèle implémentait une interface bien connue. Cette classe a été instanciée en utilisant Activator.CreateInstance()et appelée pour initialiser, puis a été passée au contrôle lui-même (inversion de contrôle?). Le contrôle a ensuite appelé diverses méthodes pour obtenir des ensembles de données ou autres informations. L'interface elle-même a été normalisée pour avoir les méthodes CRUD habituelles (lecture / écriture / liste / suppression). Il y avait également une couche DAL / ORM en dessous.

Ce n'était pas joli, mais cela fonctionnait bien. Il était facile de le tester et de le développer, et la plupart des développeurs qui se sont joints au projet allaient rapidement comprendre. Surtout, sa création était relativement simple.