This is strongly linked to these two questions:


Should Controller know about View & Model? or vice versa?

as well as this one:


In particular, one part of this answer to the third one, mentioning the way the Windows Forms / UserControl class was creating a data class instance, made me wonder about this:

When making a Windows Forms app with an MVC architecture (not the Microsoft built-in MVC framework), should a Windows Form / UserControl class either know or do anything at all except basically just draw itself? For instance, two specific cases come to mind:

  1. A data class being passed around both ways between the view and the controller to organize things and to simplify things like method interfaces.

  2. When, say, a button is clicked on the form, should the controller handle all those sorts of events directly in its own event listeners? Should event listeners internal to the view simply call callbacks that are set by the controller and then do nothing else at all? (If either, I'm leaning towards the controller handling the events.)

This is a general question of whether the view should do anything at all on its own accord once it is instantiated, except present itself to the user, but the two cases above exemplify why I'm not quite able to take the advice given from the questions above and completely follow how to apply it to this question.


This answer to a more recent question is pretty heavily linked to the first point.

  • 2
    Model View Presenter is the paradigm of choice for Winforms. See winformsmvp.codeplex.com Commented Apr 26, 2016 at 23:29
  • What is the scope or purpose of the control? That will impact if the control should implement non-drawing logic. Commented Apr 26, 2016 at 23:48

1 Answer 1


As Robert Harvey commented, MVP (model-view-presenter) is the architectural pattern of choice for Winforms. MVP is really just a flavor of MVC though.

Your form (view) should implement an interface defining the public API of the view.

FooForm : IFooView, Form

And it will expose some of its elements via properties, say maybe a textbox input.

public string FirstName
    get { return txtFirstName.Text; }
    set { txtFirstName.Text = value; }

Then, as you mentioned, the controller (Presenter) will listen for any events.

public event EventHandler Submit;

private btnSubmit_Click(EventArgs e)

In other words, keep your view as dead dumb simple as possible. It's only job is to bind data to the Form's elements and to raise events. Your controller (Presenter) is responsible for the real logic.

Your root Program.cs entry point will look something like this.

static void Main()
    var view = new FooForm();
    var presenter = new FooPresenter((IFooView)view);


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.