C# ASP.NET Codes de refactoring | Comment/Directives

Question

Je suis confronté à une énorme tâche à accomplir, commencer à recréer notre plus grand site web asp.net qui a été créé à partir d'asp classic, puis porté sur asp.net VS2003 et ensuite porté sur asp.net VS2005. Lorsque les codes sont old school, tous les accès aux données de la logique métier & se trouvent tous dans les fichiers .aspx.cs. La bonne chose est, cela fonctionne A-Ok. Maintenant, ma question est, y at-il des lignes directrices sur la façon de refactoriser le code asp.net derrière? Tels que: - dois-je créer une classe séparée pour les codes refactor ou devrais-je utiliser l'app_code pour les nouveaux fichiers pour les codes refactor? - structure de code refactor .. etc

Answer 1

Eh bien, vous voulez évidemment créer une sorte de Data Access Layer, que vous pouvez construire en tant que projet distinct.

Donc, obtenez tout votre code d'accès aux données [ADO] hors du code derrière les fichiers, et faites référence à la couche d'accès aux données.

N'hésitez pas à utiliser App_Code, mais ne le faites pas trop. Mettre trop de classes dans App_Code peut ralentir vos temps de construction.

N'importe quelles classes générales/utilitaires, n'hésitez pas à les mettre dans leur propre projet de bibliothèque de classes.

Cela devrait vous aider à démarrer.

Answer 2

Je vous recommande d'extraire d'abord la logique métier dans des classes séparées - ne vous inquiétez pas de la façon dont les classes sont nommées, ou si une autre structure ne peut pas être meilleure. Il suffit de le faire, en testant fréquemment pour s'assurer que vous n'avez rien cassé. Plus tard, vous pouvez décider à quelles classes la logique devrait vraiment être, et vous pouvez la refactoriser pour la mettre là. L'une de mes principales raisons pour suggérer cela est qu'une fois la logique métier séparée, vous pouvez créer plus facilement un ensemble complet de tests unitaires en fonction de cette logique. Vous voulez avoir des tests unitaires en place avant de commencer le refactoring pour nettoyer la structure. Tant que les tests unitaires réussissent, vous serez certain que votre refactoring n'a rien cassé.

Cela vous donnera la confiance dont vous avez besoin (et votre gestion) pour faire des choses comme créer une couche d'accès aux données séparée.

Answer 3

Je suggère que dans un premier temps, vous minimisez le code dans vos fichiers codebehind. Ceux-ci doivent avoir le code minimal requis pour récupérer l'entrée utilisateur, valider, interagir avec d'autres classes et fournir une sortie. Tout le vrai travail devrait être fait ailleurs.

Vous pouvez créer un calque de gestion (une bibliothèque de classes distincte) qui contiendra tout le code réel auquel votre frontal interagira et déléguera. À ce stade, vous pouvez essayer d'ajouter des tests d'intégration pour vous assurer que les composants de la couche de gestion fonctionnent comme prévu. Avec les tests d'intégration en place, faites quelques refactorisations pour assurer la séparation des préoccupations, et suivez le principe de la responsabilité unique. À ce stade, l'ajout de tests unitaires ne devrait pas être difficile.

Si vous avez un code d'accès aux données, vous voulez certainement que votre code soit caché derrière. Le traitement de la base de données devrait être fait au moins dans votre couche Business, ou mieux encore, le code spécifique à la base de données devrait être dans une couche distincte et utilisé via la couche Business.