Patrón de MVP, ¿cuántas vistas tiene un presentador?

Question

Estamos intentando que el patrón Model-View-Presenter se use en (virtualmente) todos los nuevos trabajos de desarrollo que emprendamos.

Creo firmemente en tener un marco para ayudar a las personas a cumplir con un requisito de diseño, tenemos algunos marcos internos para varios componentes diferentes (registro, envío de correos electrónicos, etc.), así que estoy tratando de obtener algún tipo de marco MVP desarrollado.

He logrado juntar algo que es fácil de usar para las personas que no están familiarizadas con MVP y que no está muy lejos de cómo trabajamos actualmente. El problema es que está haciendo una relación de 1 vista a 1 presentador.

Aquí es un esbozo del marco:

public abstract class Presenter<TView> where TView : IView { 
    public virtual T View { get; set; } 

    public virtual void Setup(TView view) { 
    this.View = view; 
    } 
} 

public interface IView { } 

La forma básica en que funciona es que cualquier Ver hereda creados a partir de la interfaz IView, y pasan a un clase Presentador que hereda de la Presenter clase abstracta.

Como puede ver, estoy usando los genéricos .NET para que el desarrollador tenga una buena tipa de la Vista cuando están trabajando en el presentador (y finalmente una clase que hereda del presentador).

Así que puedo configurar un componente básico de entrada como esta:

public class Login : Presenter<ILogin> { 
    public override Setup(ILogin view){ 
    base.Setup(view); 
    this.View.Login += new EventHandler(login); 
    } 
    void login(object sender, EventArgs e) { ... } 
} 

public interface ILogin : IView { 
    string Username { get; set; } 
    string Password { get; set; } 
    event EventHandler Login; 
} 

Así que como he dicho me gusta mucho esto, no forzada a escribir compilador, vistas inflexible y una MVP- como patrón.

Aunque algunas personas no están tan felices con la implementación, porque tiene una relación de 1 a 1 entre los presentadores y las vistas, y estrictamente hablando, esto no es lo que MVP debe ser.

Me pregunto qué tan válido es este argumento, en los varios proyectos que he estado siguiendo este marco (desde proyectos medianos a grandes) No he encontrado ningún buen ejemplo donde pensé "Necesito tener múltiples vistas" para este presentador ". Cuando veo la funcionalidad que se puede compartir en varias vistas, me pregunto si debería estar vinculada a un presentador en particular, o si debería estar en una clase más neutral.

¿El marco que estoy tratando de lograr demasiado lejos de MVP se llamará MVP? ¿Es la necesidad de tener múltiples puntos de vista para un presentador el objetivo principal de MVP? ¿Es posible tener un verdadero framework .NET MVP con soporte n-view?

Answer 1

No veo ningún problema con su enfoque. No es estrictamente necesario que exista una relación uno a muchos entre un presentador y las vistas; por lo general, solo tiene una vista por presentador. La idea detrás de MVP es desacoplando presentadores de vistas, para que pueda cambiar la vista más fácilmente si es necesario (por ejemplo, admitir aplicaciones web y aplicaciones de escritorio), pero eso no significa que tenga que hacerlo dinámica.

Una sugerencia: Normalmente proporciono el IView como un parámetro de constructor al Presenter. La implementación concreta de IView luego crea el presentador (ya sea mediante el código fijo new Presenter (this) o usando un contenedor IoC para obtenerlo).

Answer 2

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