So far, I have used the MVP architecture pattern a few times. Every now and then, I wonder whether my Presenter should depend on my View or vice versa, that is the View depends on my Presenter.


Though the sample code provided is in C#, I don't mind about the language. My question targets more precisely the MVP pattern. Additionally, it was provided off the top of my head solely to help illustrate my concern. It may not compile.

Here's a short sample of what I'm used to do:

public interface IHasUiHandler<H> where H : IUiHandler {
    H Handler { set; }

public interface IView {
    void Close();
    void Hide();
    void Show();

public abstract class Presenter<V> where V : IView {
    protected Presenter(V view) { this.view = view; }

    public void CloseView() { view.Close(); }
    public void HideView() { view.Hide(); }
    public void ShowView() { view.Show(); }

    private readonly V view;

And let's say I'm creating a Customer Management feature.

public interface ICustomerManagementUiHandler : IUiHandler {
    Customer CreateNewCustomer();
    IList<Customer> ListCustomers();
    void RemoveCustomer(Customer customer);
    Customer UpdateCustomer(Customer customer);

public class CustomerManagementPresenter : Presenter<ICustomerManagementView>
                                         , ICustomerManagementUiHandler {
    public CustomerManagementPresenter(ICustomerManagementView view
        , CustomerManagementService service) 
        : base(view) {
        view.Handler = this;
        customers = service;

    public Customer ChangeExistingCustomer(Customer customer) { return customers.Update(customer); }
    public Customer CreateNewCustomer(Customer customer) { return customers.Add(customer); }
    public IList<Customer> ListCustomers() { return customers.List(); }
    public void RemoveCustomer(Customer customer) { customers.Remove(customer); }

    private readonly CustomerManagementService customers;

public interface ICustomerManagementView : IHasUiHandler<ICustomerManagementUiHandler> {        

public class CustomerManagementForm : Form, ICustomerManagementView {
    public CustomerManagementForm() { }

    public ICustomerManagementUiHandler Handler { 
        private get { return handler; } 
        set { if (handler == null) handler = value; } 

    private void changeCustomerButton_Click(object sender, EventArgs e) {
        if (Handler == null) 
            throw new InvalidOperationException("Can't change customer. No handler specified.");

    private void createCustomerButton_Click(object sender, EventArgs e) {                        
        if (Handler == null) 
            throw new InvalidOperationException("Can't add new customer. No handler specified.");
        Handler.CreateNewCustomer(); // No parameters for sample simplicity sake.

    private void deleteCustomerButton_Click(object sender, EventArgs e) {
        if (Handler == null) 
            throw new InvalidOperationException("Can't add new customer. No handler specified.");

    private readonly ICustomerManager manager;
    private ICustomerManagementUiHandler handler;

I feel like the View should depend on the presenter, so that there would be no need for a Handler property in the View itself. Then the Presenter could depend on the data access service or the like to handle the business entities and the like.

This would wave away the Method Injection, which is a benefit, IMHO. Plus it seems to reduce complexity for waving away both the IHasUiHandler and IUiHandler interfaces. This makes it a easily testable code because the Presenter is an easily-tested class.

However, this way I'm afraid that the Presenter has no real handle over the view which it should be able to either show or hide. So this is where I'm growing confused about which shall depend on which.

  • 2
    If the View dependended on the Presenter, wouldn't it defeat the pattern's purpose? The View should be just that - a View that's only concerned with presentation concerns. This question is on the fence of high-level design, which would be better addressed on Programmers.SE - to be on-topic on Code Review we need to see your actual, working code, in full context and glory :) Commented Sep 9, 2014 at 16:23
  • I have often seen a Presenter being Setter Injected to the view, or else, before DI, instantiating a new presenter from within the view itself so that the code becomes testable. Even if the View depended on the Presenter, the Presenter still decouples the code from the UI and can be reused over and over again, and is easily testable. Commented Sep 9, 2014 at 16:30
  • related (possible duplicate): Loose Coupling Presenter to View in MVP
    – gnat
    Commented Sep 9, 2014 at 16:58
  • 1
    My personal preference is a thin view. I prefer my views (especially in .NET) to raise events and expose functions. As a view I can return data, and i can raise events but other than that i have no clue what's going on outside my world. Commented Sep 10, 2014 at 20:10
  • Yes. I used to use the Observer Pattern as well, and this may become hard to debug and maintain due to the pattern's nature. Instead, I began to use interfaces so that the view has to fulfill the contract of having a property called Handler, and through this exposed property, the Presenter sets itself as the handler. Then, the view uses the Hollywood Principle and call upon the required method on its handler, which could be anything that implements IUiHandler. Commented Sep 10, 2014 at 20:18

1 Answer 1


Truthfully, it doesn't really matter.

There isn't much difference between a presenter-first design where the presenter subscribes to events on the view (observer pattern) and a view-first design where the view calls methods on the presenter instead of raising those events (potentially using command pattern, such as in MVVM).

So long as you inject an interface of the view into the presenter or an interface of the presenter into the view, they are sufficiently de-coupled.

  • This comforts me. In fact, I couldn't see much difference neither, so I wondered whether I missed something or I was right about it. Commented Sep 10, 2014 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.