Refactoring WinForm ClickNCode a MVP Vista passiva

Question

Sto tentando di ridefinire un'applicazione Winform esistente per utilizzare il pattern MVP Passive View. L'interfaccia utente dell'applicazione, la logica aziendale e il codice di archiviazione dei dati sono stati liberamente mescolati per anni. Sembra che sia iniziato con livelli separati o qualcuno abbia tentato di separarlo in livelli. In ogni caso i confini del livello non sono stati rispettati.

Poiché i moduli manipolano direttamente gli oggetti dominio e l'origine dati (e viceversa), il mio primo compito è creare oggetti relatore/controllore e delegare tali responsabilità.

L'applicazione è un'app .NET 1.1 e sto sviluppando in VS.NET 2003 con un componente aggiuntivo di refactoring piuttosto limitato. Ho usato un generatore di test per il codice esistente per creare i test dell'unità della piastra della caldaia, quindi ho esaminato e modificato manualmente ciascun test. Certo, questo finisce per testare cosa fa il codice, non necessariamente ciò che si suppone di fare. Per le nuove classi sto facendo TDD.

Eventuali suggerimenti, risorse, insidie ​​da considerare con uno sforzo di refactoring di questa scala?

Un paio di risorse già ho a mia disposizione:

• Raccolta di libri di programmazione; Refactoring, PEAA, welc
• Internet (ovviamente)
• Grandi quantità di bevande contenenti caffeina

Update: Come esempio quali misure vorresti prendere a trasformare questo:

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(); 
    } 

In questo:

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

Answer 1

L'approccio che ho adottato è anche spostare prima il codice dai gestori di eventi. Essenzialmente ho collocato una classe accanto al modulo, che implementa i gestori di eventi e mantiene lo stato dell'interfaccia utente accanto ai controlli.

Attraverso questa mossa ho ottenuto una separazione molto chiara della forma e dell'interazione effettiva con l'app rimanente e sono stato in grado di introdurre test a quel livello. Un altro risultato è stato che la vista diventa passiva abbastanza rapidamente.

Rifacifico il presentatore (che ora contiene i gestori di eventi) in un passaggio separato e introduce oggetti di dominio solo dopo che ho spostato tutti gli usi di questi oggetti da tutte le forme.

Quindi sarebbero i miei passi:

1. rimuovere la dipendenza UI dalla logica
2. Creare oggetti di dominio (se non disponibile già)
3. refactoring i presentatori di utilizzare gli oggetti di dominio
4. Introdurre servizi secondo la tua scelta di design mentre sei a questo

Mentre facevo questo ho iniziato a introdurre effettuare test sui confini appena introdotti per garantire che non sto rompendo il codice di lavoro o per trovare bug nel codice esistente che sto spostando.

Answer 2

Se si dispone del tempo, è consigliabile primo scrivere alcuni test del fumo utilizzando framework di test WinForms come White sull'applicazione esistente. In questo modo sarai in grado di controllare eventuali bug appena introdotti quando avvii il refactoring del codice.

Answer 3

È possibile trovare le risposte a Implementing MVC with Windows Forms utile in quanto si parla di diverse opzioni quando attuazione MVC e MVP