Handling Parent-Child Relationship using MVP within a WinForms Application

Question

I recently asked on Programmers:

How should one handle a Parent-Child relationship using MVP?

Based on the comments received, I tried this:

IParentView

public interface IParentView { }

IChildView

public interface IChildView<V> where V : IParentView {
    void Show(V parentView);
}

IChildPresenter

public interface IChildPresenter<V> where V : IParentView {
    void ShowView(V parentView);
}

CustomerManagementPresenter

public class CustomerManagementPresenter : Presenter<ICustomerManagementView>
    , ICustomerManagementUiHandler
    , IChildViewPresenter<IMainView> {
    public CustomerManagementPresenter(ICustomerManagementView view
        , ICustomerManagementService service) : base(view) {
        view.Handler = this;
        if (service == null) throw new ArgumentNullException("service");
        customerManagementService = service;
    }

    public void LoadCustomers() {
        var customers = customerManagementService.GetCustomers();
        View.ViewModel.Customers = customers;
    }

    public void ShowView(IMainView parentView) { View.Show(parentView); }

    private readonly ICustomerManagementService customerManagementService;
}

IMainView

public interface IMainView : IView, IParentView, IHasUiHandler<IMainViewUiHandler> { }

MainPresenter

public class MainPresenter : Presenter<IMainView>, IMainViewUiHandler {
    public MainPresenter(IMainView view, ICustomerManagementPresenterFactory factory)
        : base(view) {
        view.Handler = this;
        if (factory == null) throw new ArgumentNullException("factory");
        this.customerManagementPresenterFactory = factory;
    }

    public void ManageCustomers() {
        var p = customerManagementPresenterFactory.Create();
        var parent = this.View;
        p.ShowView(parent);
    }
}

CustomerManagementForm

public partial class CustomerManagementForm : Form, IMainView {
    public CustomerManagementForm(CustomerManagementViewModel viewModel) {
        InitializeComponent();

        if (viewModel == null) throw new ArgumentNullException("viewModel");

        customerManagementViewModel = viewModel;
        customerManagementViewModel.PropertyChanged += 
            new PropertyChangedEventHandler(
                customerManagementViewModel_PropertyChanged);
    }

    public ICustomerManagementUiHandler Handler { get; set; }
    public string Message { get; set; }
    public string Title { get { return Text; } set { Text = value; } }
    public CustomerManagementViewModel ViewModel { 
        get { return customerManagementViewModel; } 
    }    

    public void Show(IMainView parent) {
        MdiParent = (Form)parent;
        Show();
    }    

    private void CustomerManagementForm_Load(object sender, EventArgs e) {
        Handler.LoadCustomers();
    }

    private void CustomerManagementViewModel_PropertyChanged(
        object sender
        , PropertyChangedEventArgs e) {
        customerManagementViewModelBindingSource.DataSource = ViewModel;
    }

    private readonly CustomerManagementViewModel customerManagementViewModel;
}

I believe I could reduce complexity or repetition with my IChildPresenter and IChildView which are pretty similar. Besides, The Show() methods belongs expressly to the views, whilst ShowView() methods actually belongs to presenters. I tend to follow some such basic nomenclature to make it more understandable.

So now I wonder, what do you guys think of this approach?

Did I miss the point?

Any possible imporvement?

Answer 1

I'm no expert in design patterns, but I fail to see the benefit in having a completely empty interface.

public interface IParentView { }

Interfaces do two things for us.

1. They enforce a contract. Anything implementing this interface must have this specific public api. Which allows for...
2. The ability to code against an expected api, not an implementation.

While you've done a good job of coding against IParentView instead of IChildView, what does the parent view get us? Nothing as far as I can tell. There's no real contract being made here, so there's no reason you couldn't have coded directly against IChildView. (Which, at that point, would not be a good name.)

But don't take just my word for it, 24 people on stack overflow agree that this pattern is a code smell.