In a .NET Windows Forms app with a custom MVC, should a custom UserControl (view) implement any non-animating logic on its own?

Question

This is strongly linked to these two questions:

https://stackoverflow.com/q/15800945/279112

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

as well as this one:

https://codereview.stackexchange.com/q/126373/39907

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.

UPDATE

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

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)
{
    Submit?.Invoke(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.

[STAThread]
static void Main()
{
    var view = new FooForm();
    var presenter = new FooPresenter((IFooView)view);

    Application.Run(view);
}