ASP classique vers ASP.net ou ASP.net MVC

Nous avons une application web qui est développée en ASP classique et qui a évolué sur 5 ans vers sa forme actuelle qui a des centaines de pages, une énorme base de données et plus de 10000 utilisateurs actifs parcourant au moins plus de 10 pages par jour.

Maintenant, nous voulions le mettre à niveau vers la dernière version de .net. Au début, nous pensions penser à réécrire toute l'application, mais après avoir analysé le scénario, nous avons constaté que ce n'était pas une option viable non plus suggérée par de nombreux experts. Nous n'avons pas encore décidé de la façon de procéder autrement, mais nous avons réfléchi à la manière de réécrire les visages.

Option 1: Nous avons pensé identifier les principaux modules de cette application et les réécrire un par un en séparant l'application en différentes couches telles que la base de données (existante), puis la logique métier et la vue. De cette façon, les modules nouvellement développés seront ajoutés au système existant et les nouvelles pages remplaceront les anciennes pages de ce module particulier. Dans le même temps, nous pouvons tester les nouvelles couches à côté de l'ancien système et les libérer une fois que nous sommes confiants. Nous avons également pensé à développer une structure de type API pour la logique métier et celle-ci sera accessible par vue comme une application externe.

Option 2: Pour le moment, nous avons créé un module simple et l'avons utilisé dans une page ASP classique via un IFrame, bien qu'il soit assez gênant d'envoyer des données entre l'ASP classique et une nouvelle page dans l'IFrame.

Ceci est juste dans la phase de planification sur la façon dont nous devrions réaliser la réécriture de l'application entière sans déranger la base d'utilisateurs.

Je veux obtenir les points de vue, opinions et suggestions d'autres programmeurs sur la manière de procéder dans un tel scénario? Si quelqu'un a fait face à ce genre de scénario, veuillez également partager votre opinion.

J'aimerais également savoir que l'utilisation de ASP.net MVC va m'aider dans ce domaine?

MISE À JOUR : Merci pour les deux réponses pour avoir affiché vos points de vue. Voudrait obtenir plus d'entrées sur les deux options que j'ai spécifiées ci-dessus lors de la migration de l'application de asp classique vers asp.net ou asp.net mvc. Ce serait d'une grande aide pour moi, si vous pouvez tous à travers vos points de vue, vos points de vue et vos réflexions sur la partie migration plutôt que sur le point de choisir asp.net ou asp.net mvc.

Permettez-moi de commencer par dire: "Je ressens votre douleur, brutha." Je suis passé par là il y a 3 ans, et j'aurais aimé que MVC soit arrivé à maturité à ce stade parce que la solution WebForms que j'ai conçue ressemble assez bien au modèle MVC sans que les bibliothèques Microsoft soient construites pour moi (bien sûr, il y avait plusieurs flagrants "Pourquoi diable" ai-je fait ça "différences".

J'ai également fini par utiliser des iFrames pour gérer les différences de contenu en utilisant .Net comme application parent et asp classique comme esclave. J'ai développé l'architecture du framework dans .Net et l'ai implémentée. Les pages asp classiques ont ensuite été "triées" de morceaux de présentation inutiles (inclus et ainsi de suite) et chargées dans iFrames. Les données ont ensuite été transmises via l'URL à l'aide d'un chiffrement personnalisé. Pour vous assurer que l'authentification ne pouvait pas être usurpée facilement et que la page était accessible en craquant la chaîne de requête, nous avons également utilisé des gestionnaires Wildcard dans IIS qui forçaient .Net à s'authentifier avant d'analyser les pages asp classiques.

Compte tenu de cela, ma recommandation serait de se diriger immédiatement vers MVC.

1. MVC vous donnera accès au routage au niveau global.asax. Avec une manipulation intelligente d'un contrôleur, vous pouvez développer vos modèles de manière appropriée et avoir un contrôleur commun qui gère toutes les demandes d'asp classiques, si nécessaire.
2. MVC simplifiera l'ajout d'un projet de test et vous permettra de refactoriser des éléments d'application individuels en fonction de la nouvelle structure du modèle tout en offrant une couverture de test adéquate pour vous assurer que tout se passe bien. La valeur de ceci est absolument incalculable car dans tout code refactor, la couverture du code est une énorme préoccupation.
3. MVC suit une approche plus scénarisée de la présentation que WebForms. WebForms essaie de tout mélanger comme s'il s'agissait d'une sorte d'application dynamique (ce qui n'est pas le cas), et cela peut être un choc culturel pour les personnes habituées à l'asp classique. Ne vous méprenez pas, vos développeurs vont subir un choc culturel, peu importe où vous allez, mais si vous pouvez retirer une partie de ce choc de la couche de présentation, vous obtiendrez peut-être plus de succès.

J'aime à la fois WebForms et MVC (bien que j'avoue avec l'introduction de Razor, je deviens un peu biaisé envers MVC). Ils ont tous les deux leur place, et je pense qu'une application telle que celle que vous décrivez peut être parfaitement adaptée à une implémentation MVC, en particulier compte tenu de la nature "décalée" que vous devrez adopter pour déployer des éléments d'application refactorisés.

Quelle que soit la façon dont vous allez, je pense que vous devez vous assurer que l'application .Net est toujours l'application parente quand il s'agit d'authentification / autorisation / routage / etc. Un de mes collègues a implémenté sa migration sur une application similaire avec asp classique comme parent, et il a eu un grand nombre de problèmes quand il s'agit finalement de tout réintégrer.

Opter pour ASP.NET MVC ne va pas nécessairement rendre la transition plus facile, et cela peut en fait la rendre plus difficile. Cependant, lorsque vous avez déjà choisi de passer par cette grande entreprise, pourquoi ne pas prendre le temps d'aller de l'avant et de passer à la plate-forme qui correspond le mieux à vos plans?

La migration vers ASP.NET (sans MVC) sera "plus facile" dans le sens où vous pouvez généralement faire des ports droits de votre logique existante sans avoir à faire beaucoup de refactoring, à condition de ne pas faire beaucoup de choses exotiques avec ASP classique. Les résultats seront satisfaisants et relativement familiers aux personnes qui connaissent déjà l'application. Vous obtiendrez des avantages dans le sens où chaque application portée d'ASP classique vers ASP.NET bénéficiera d'avantages .

La migration vers ASP.NET MVC va demander plus de travail. Il faudra probablement réorganiser votre modèle d'application pour l'adapter au modèle MVC . C'est généralement une bonne chose (tm) car elle encourage les bons comportements comme la séparation des préoccupations. L'application résultante ne ressemblera probablement pas à tout ce que vous avez, à l'exception des éléments logiques de base. Vous bénéficierez également d' autres avantages . Ce sera un grand changement de culture et il faudra une (ré) éducation de l'équipe de développement pour comprendre "comment écrire MVC" correctement.

Il convient de noter que Microsoft n'abandonne pas les formulaires Web selon ScottGu (il y a un an), mais je ne pense pas qu'il soit difficile de dire que si / quand ils décident de supprimer l'une de ces deux technologies, ce sera WebForms.

Je suis totalement d'accord que ASP.NET MVC est la voie à suivre. Ce ne sera pas facile, ce ne sera pas plus facile, mais c'est certainement beaucoup plus à l'épreuve du temps que WebForms. Bien que WebForms n'ait certainement pas été abandonné, les applications qui les utilisent deviennent de plus en plus lourdes à maintenir à mesure que les applications deviennent de plus en plus grandes.

Je déconseille fortement l'utilisation de WebForms sur les "grandes" applications.

J'aime l'option 1) (avec MVC) beaucoup mieux que l'option 2) car elle vous permet de faire évoluer l'application de manière incrémentielle, sans avoir à coupler trop les deux applications comme vous le feriez avec l'approche iFrames.

J'ai eu une certaine expérience de la migration d'une ancienne application vers ASP.Net et l'un des défis était de partager certaines des ressources telles que l'état de la session entre les deux applications. Cela peut être résolu en demandant à une application d'appeler l'autre côté serveur via les informations de cookie du navigateur de l'utilisateur. Un autre partage d'informations entre les applications peut également être effectué via le routage d'URL et les chaînes de requête, ce qui est une approche naturelle avec MVC.

En outre, l'identification des modules appropriés à migrer en premier peut être un défi, mais vous pouvez commencer avec toutes les nouvelles fonctionnalités développées sur MVC pour éviter que plus de choses se retrouvent dans le garage à migrer. Ensuite, choisissez peut-être des sections qui ont un important retard de retouches ou de corrections de bugs à faire ensuite car l'application MVC deviendrait alors une forme de refactoring, en utilisant votre ancien système pour établir les résultats attendus comme vous le suggérez. N'oubliez pas de profiter également de la testabilité de MVC en ajoutant des tests unitaires et des tests d'acceptation automatique (par exemple SpecFlow / Watin) lors de ce refactoring. Un des avantages de ce dernier type de test est que vous pouvez vérifier qu'ils transmettent l'ancien système, puis appliquer les mêmes tests à votre nouveau code pour ce refactoring et celui à venir.