Refactoring pour séparer la logique métier du code derrière

Question

J'ai hérité d'un projet asp.net et je trouve que le code derrière les pages contient beaucoup de logique métier.

J'ai décidé que, dans la plupart des cas, il est préférable de laisser le code de travail en place que d'essayer de faire un refactoring massif. Toutefois, certaines pages exécutent des fonctionnalités qui pourraient être réutilisées dans les utilitaires de ligne de commande pour le traitement par lots. Je voudrais concentrer mes énergies sur ces pages, en refacturant la logique métier et en référençant cela dans d'autres utilitaires.

Je cherche actuellement à refactoriser cette page particulière qui a 6200 lignes de code dans le code derrière. Ce que je trouve c'est que c'est un travail très fastidieux essayant de localiser les dépendances entre le code derrière et les objets spécifiques de la page. Je me demande si quelqu'un connaît un outil, une fonctionnalité VS ou une méthode qui me permettrait de localiser et d'attaquer systématiquement ces dépendances? Quelque chose qui me permettra d'identifier n'importe quelle zone du code qui référence ViewState, une zone de texte, un panneau, une liste déroulante, etc., afin que je puisse déplacer ces références aux paramètres de méthode et finalement sortir cette fonctionnalité de la classe.

Answer 1

Je commencerais par examiner toute méthode qui ne suit pas le Single Responsibility Principle et les décomposer afin qu'ils le fassent. Une fois cela fait, vous devriez avoir une idée de ce que le code fait et vous devriez pouvoir regrouper le code plus facilement et le déplacer dans des classes dédiées pour les groupes créant les objets nécessaires à utiliser au fur et à mesure. Je trouve ReSharper est un outil très utile pour aider à faire tout cela. En fin de compte, vous aurez toujours besoin d'avoir une bonne compréhension des principes fondamentaux dans le code avant de pouvoir refactoriser avec succès.

Nous avons tous été là à un moment donné et vous avez ma plus profonde sympathie, mais votre volonté de l'essayer du tout signifie que vous êtes déjà dans la bonne direction. Bonne chance!

Answer 2

Une façon je peux immédiatement penser est Compile ensuite dans les assemblées et analyser l'ensemble à l'aide NDepend

http://www.ndepend.com/Features.aspx#DependencyCycle

alt text http://www.ndepend.com/Res/NDependBig03.PNG

Answer 3

Wow abord désolé de là que. Quiconque mettrait 6000 lignes de code dans le code mérite d'être claqué :)

Maintenant, j'ai déjà fait ce genre de refactoring. J'aborder ce en quelques étapes:

(1) Créer des régions logiques #Region et #endregion Like - Enregistrer Méthodes, Méthodes de charge ou (2) si vous pouvez créer des objets métier physiques à partir de ces régions dans votre business layer (3) Une fois que vous avez terminé, référez tout votre code à la classe appropriée. Je comprends que vous voulez un outil pour faire tout cela, mais j'ai peur de faire cela, vous allez creuser le trou du trou. Comprendre le code et le déplacer méthode par méthode vous donnera une meilleure compréhension.