Refactoring WinForm ClickNCode à MVP Passive View

Question

Je tente de refactoriser une application Winform existante pour utiliser le modèle MVP Passive View. L'interface utilisateur, la logique métier et le code de stockage des données de l'application ont été mélangés librement pendant des années. On dirait que soit il a commencé avec des couches séparées ou quelqu'un a tenté de le séparer en couches. Dans tous les cas, les limites de la couche n'ont pas été respectées. Comme les formulaires manipulent directement les objets de domaine et la source de données (et vice versa), ma première tâche consiste à créer des objets de présentateur/contrôleur et à déléguer ces responsabilités.

L'application est une application .NET 1.1 et je développe dans VS.NET 2003 avec un complément de refactoring plutôt limité. J'ai utilisé un générateur de test pour le code existant pour créer les tests unitaires de la plaque de chaudière, puis j'ai passé en revue et modifié manuellement chaque test. Certes, cela finit par tester ce que fait le code, pas nécessairement ce qu'il est censé faire. Pour les nouvelles classes, je fais TDD.

Des conseils, des ressources, des pièges à surveiller avec un effort de refactoring de cette échelle?

Quelques ressources que je l'ai déjà à ma disposition:

• Collection de livres de programmation; refactorisation, PEAA, WELC
• Internet (évidemment)
• De grandes quantités de boissons contenant de la caféine

Mise à jour: À titre d'exemple quelles mesures prendriez-vous pour transformer ceci:

private void OneOfManyFormEventHandlers(object sender, System.EventArgs e) 
    { 
     string LocalVariable; 
     decimal AnotherLocal; 
     if (!this._SomeDomainObject.SomeMethod(ClassField, out LocalVariable, out AnotherLocal)) 
     { 
      MessageBox.Show("An error occurred calling method"); 
      return; 
     } 

     this.FormControl.Value = LocalVariable; 
     this.AnotherFormContorl.Value = AnotherLocal; 

     this.AnotherPrivateMethod(); 
    } 

Dans ce:

private void OneOfManyFormEventHandlers(object sender, System.EventArgs e) 
    { 
     this.FormPresenter.DoSomething(); 
    } 

Answer 1

L'approche que j'ai adoptée consiste à déplacer le code des gestionnaires d'événements. Essentiellement, j'ai placé une classe à côté du formulaire, qui implémente les gestionnaires d'événements et maintient l'état de l'interface utilisateur à côté des contrôles. Par ce mouvement, j'ai obtenu une séparation assez claire de la forme et de l'interaction réelle avec l'application restante et j'ai pu introduire des tests à ce niveau. Un autre résultat de ceci était que la vue devient passive assez rapidement.

Je refactorise le présentateur (qui contient maintenant les gestionnaires d'événements) dans une étape séparée et j'introduis les objets de domaine seulement après avoir déplacé toutes les utilisations de ces objets hors de toutes les formes.

Alors mes étapes seront:

1. Supprimez la dépendance de l'interface utilisateur de la logique
2. Créer des objets de domaine (si non disponible déjà)
3. refactoring les présentateurs d'utiliser le domaine des objets
4. Initiez services selon votre choix de conception pendant que vous y êtes

Pendant que je faisais cela, j'ai commencé à présenter en testant les limites nouvellement introduites pour m'assurer que je ne casse pas le code de travail ou pour trouver des bogues dans le code existant que je déménage.

Answer 2

Si vous en avez le temps, je recommanderais d'abord écrire des tests de fumée en utilisant des frameworks de test WinForms comme White sur l'application existante. De cette façon, vous serez en mesure de vérifier les bogues nouvellement introduits lorsque vous commencez à refactoriser le code.

Answer 3

Vous pouvez trouver les réponses à Implementing MVC with Windows Forms utiles car ils parlent des différentes options lors de la mise en œuvre MVC et MVP