¿Cuál es una buena práctica para dividir a los presentadores en un patrón de interfaz MVP que ha crecido demasiado?

Question

Un problema con el que me he encontrado con frecuencia últimamente es el problema de que mis clases de presentador crecen demasiado. Por lo general, puedo cortar una clase grande regular sin perder el ritmo. Pero los presentadores a veces son un poco más difíciles de reducir, sin hacer que el código sea más difícil de seguir.

Especialmente cuando la página comienza a llenarse con controles orientados a CRUD. A veces divido los controles, pero si se ven afectados por otros controles, la lógica de coordinación es compleja en sí misma. A veces divido la recuperación de datos de la lista o la cuadrícula, pero a veces eso puede tener dificultades similares.

¿Existen técnicas, reglas generales o áreas comunes que refactorice de sus presentadores?

Answer 1

Usualmente uso dos enfoques:

1. Extraer y delegar reglas de negocio a clases de dominio.
2. Particione la vista en controles lógicamente relacionados y luego cree una nueva interfaz de vista para cada partición. Luego puede dividir su presentador en esas mismas líneas. Si la plataforma que usa admite grupos de componentes de subformulario (controles de usuario de C #, marcos de Delphi, etc.), esta es una forma poderosa de hacer controles reutilizables.

Update

Al dividir vistas, normalmente empiezo dividiendo la interfaz y haciendo que mi formulario implemente varias interfaces.

public class ComplexForm: Form, ISubView, IOtherSubView
{
    ...
}

Luego dividí el presentador en la cantidad de vistas que he creado.

public class SubViewPresenter
{
    private ISubView subView;
    ...
}

public class OtherSubViewPresenter
{
    private IOtherSubView otherSubView;
    ...
}

Puede ir un paso más allá y mover la implementación de ISubView e IOtherSubView a los controles del usuario o dejarlo como está. Si está utilizando un patrón de vista pasiva , este es un juego de niños ya que el formulario solo maneja la lógica de la interfaz de usuario de todos modos. Una vez que divido al presentador, trato de evitar la comunicación directa entre los presentadores. Si se necesita alguna comunicación, trato de hacerlo indirectamente a través de objetos de dominio.

Answer 2

Intente extraer el código que realiza actividad fuera de pasar datos a su DAL o empujarlo a la vista. Por ejemplo, si tiene que hacer actualizaciones por correo electrónico o realizar una lógica de negocios, intente extraerlas en clases separadas. A menudo trato con el mismo problema y he estado tratando de mover tanta lógica como sea posible a las clases individuales de dominio / entidad y realizar la validación allí.

Espero que esto sea útil.