MVP pattern, how many views to a presenter?

Question

We are trying to get the Model-View-Presenter pattern used on (virtually) all new dev work that we undertake.

I'm a strong believer in having a framework to help people meet a design requirement, we have a few in-house frameworks for various different components (logging, email sending, etc), so I'm trying to get some kind of MVP framework developed.

I've managed to put together something that is easy to use for people who aren't familiar with MVP and that isn't too far removed from how we currently work. The problem is that it's doing a relationship of 1 view to 1 presenter.

Here's a rough outline of the framework:

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 { }

The basic way that it works is that any View created inherits from the IView interface, and passed to a Presenter class which inherits from the Presenter abstract class.

As you can see I'm using .NET generics so that the developer will have strong typing of the View when they are working on the presenter (and then ultimately a class inheriting from the presenter).

So I can set up a basic login component like this:

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

So as I said I quite like this, there's compiler enforced typing, strongly typed views and a MVP-like pattern.

Some people though are not quite as happy with the implementation, because it has a 1 to 1 relationship between presenters and views, and strictly speaking this isn't how MVP is meant to be.

I question how valid this argument really is, on the several projects I have been trailing this framework with (ranging from medium to large projects) I haven't found any good example where I thought "I need to have multiple views for this presenter". When I see functionality which can be shared across multiple views I question if it should even be tied to a particular presenter, or whether it should be in a more neutral class.

Is the framework I'm trying to achieve too far from MVP to be called MVP? Is the need to have mutliple views to a presenter the primary goal of MVP? Is it even possible to have a true .NET MVP framework with n-view support?

Answer 1

I don't see a problem with your approach. You don't strictly need to have a one-to-many relationships between a presenter and views - usually you only have one view per presenter. The idea behind MVP is decoupling presenters from views, so that you can switch the view more easily if you need to (for example, supporting both Web application and a desktop application), but that doesn't mean you have to make it dynamic.

One suggestion: I usually supply the IView as a constructor parameter to the Presenter. The concrete implementation of IView then creates the presenter (either by hard-coded new Presenter (this) or using an IoC container to get it.