Refactorización de WinForm ClickNCode a MVP Passive View

Question

Estoy intentando refactorizar una aplicación Winform existente para usar el patrón de MVP Passive View. La interfaz de usuario, la lógica comercial y el código de almacenamiento de datos de la aplicación se han entremezclado libremente durante años. Parece que comenzó con capas separadas o alguien intentó separarlo en capas. En cualquier caso, los límites de la capa no fueron respetados.

Dado que los formularios manipulan directamente los objetos de dominio y la fuente de datos (y viceversa), mi primera tarea es crear objetos de presentador/controlador y delegar esas responsabilidades.

La aplicación es una aplicación .NET 1.1 y estoy desarrollando en VS.NET 2003 con un complemento de refactorización bastante limitado. Utilicé un generador de prueba para el código existente para crear las pruebas de la unidad de la placa de la caldera y luego revisé y edité a mano cada prueba. Por supuesto, esto termina probando lo que hace el código, no necesariamente lo que se supone que debe hacer. Para las nuevas clases, estoy haciendo TDD.

¿Algún consejo, recurso, trampas a tener en cuenta con un esfuerzo de refactorización de esta escala?

Un par de recursos que ya tengo a mi disposición:

• colección de libros de programación; Refactoring, PEAA, WELC
• El Internet (obviamente)
• grandes cantidades de bebidas con cafeína

Actualización: A modo de ejemplo ¿qué medidas tomaría usted para convertir esta:

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

En esto:

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

Answer 1

El enfoque que he tomado es quitar primero el código de los controladores de eventos. Esencialmente, he colocado una clase al lado del formulario, que implementa los controladores de eventos y mantiene el estado de la interfaz de usuario al lado de los controles.

A través de este movimiento he ganado una separación bastante clara de la forma y la interacción real con la aplicación restante y pude introducir pruebas en ese nivel. Otro resultado de esto fue que la vista se vuelve pasiva bastante rápido.

Refactorizo ​​el presentador (que ahora contiene los controladores de eventos) en un paso por separado e introduzco objetos de dominio solo después de haber movido todos los usos de estos objetos de todas las formas.

Así que mis pasos serían:

1. eliminar la dependencia de interfaz de usuario de la lógica
2. Crear objetos de dominio (si no está disponible ya)
3. Refactor los presentadores de usar el dominio objetos
4. Presente servicios según su elección de diseño mientras usted está en ello

Mientras hacía esto comencé a presentar Pruebas en los nuevos límites introducidos para garantizar que no estoy rompiendo código de trabajo o para encontrar errores en el código existente que estoy moviendo.

Answer 2

Si tiene tiempo, recomendaría primero escribiendo algunas pruebas de humo usando marcos de prueba de WinForms como White en la aplicación existente. De esta forma, podrá comprobar si hay errores recientemente introducidos cuando comience a refactorizar el código.

Answer 3

Usted puede encontrar las respuestas a Implementing MVC with Windows Forms útil ya que hablar de las diferentes opciones a la hora de aplicación MVC y MVP