How should one implement the communication between classes in an MVC pattern?

Question

Preamble: This question is not about ASP.NET MVC Framework.

Edit: To be even more clear the application is a game written in C# so various web frameworks are not applicable.

---

How should I best connect classes with events when building something using the MVC pattern?

I'm wanting to write some MVC code so I can learn more about the design pattern. I understand why each of these three elements of the pattern should be separate, but I'm not exactly certain how to implement connecting them together. I'm writing this in C#, which I'm also new with, and it strikes me that events should be used. I'm mainly unsure of how I should properly subscribe/unsubscribe to the events, and I need a sanity check.

For example I'll post the View/Controller classes. In this example the View wants to send a DataRequest event, and the Controller wants to subscribe to that so as to pass that along to the Model. On the other side of things the Controller will at some point raise a DataUpdated event that the View should subscribe to. Does the way I've implemented how they're subscribing to each other make sense?

////////////////////////////////////////////////////
public class UIScreenView
{
    public event System.EventHandler<System.EventArgs> DataRequestedEvent;

    //====================================
    private void DataUpdatedEventHandler(object sender, System.EventArgs args);


    //====================================
    //====================================
    public void Subscribe(UIScreenController controller)
    {
        controller.DataUpdatedEvent += DataUpdatedEventHandler;
        controller.Subscribe(this);
    }

    //====================================
    //====================================
    public void UnSubscribe(UIScreenController controller)
    {
        controller.DataUpdatedEvent -= DataUpdatedEventHandler;
        controller.UnSubscribe(this);
    }
}

And the Controller:

public class UIScreenController
{
    private UIScreenView view;

    public event System.EventHandler<System.EventArgs> DataUpdatedEvent;

    private void DataRequestedEventHandler(object sender, System.EventArgs args);

    public void Init(UIScreenView v)
    {
        view = v;

        if (view != null)
        {
            view.Subscribe(this);
        }
    }

    ~UIScreenController()
    {
        if (view)
        {
            view.UnSubscribe(this);
            view = null;    
        }
    }

    public void Subscribe(UIScreenView view)
    {
        view.DataRequestedEvent += DataRequestedEventHandler;
    }

    public void UnSubscribe(UIScreenView view)
    {
        view.DataRequestedEvent -= DataRequestedEventHandler;
    }

    private void DataRequestedEventHandler(object sender, System.EventArgs args)
    {
        //request data from model
    }
}

Answer 1

What you have done and tried to make is is MVP pattern, not MVC. In short, MVC pattern is used for request-response architecture and not event driven. The flow is:

• UI do the request
• Controller accept the request
• Controller process the request (such as accessing model, etc)
• Controller send the response to UI

If you want to implement it in C#, I assume winform, then your request will be handled inside events. Lets say in your game you choose the menu Load Game, where afterwards need to show the saved game data.

The following example is just an illustration, so expect the non-real life logic to apply. The controller will be like:

public class SaveDataController
{
    public SaveData[] GetSaveData()
    {
        return Model.GetSaveData();
    }
}

And the UI will be like:

public void LoadGameButton_Click(object sender, EventArgs e)
{
    SaveDataController controller = new SaveDataController();
    SaveData[] saveData = controller.GetSaveData();
    SaveDataList.DataSource = saveData;
}

This example shows that the request to controller are being initiated in a button click event.

As other already said, the MVC architecture is not suited for non-web application (or event driven) as it is does not handle event methods. Most of the UI logic will be handled in event.

Answer 2

First, what you describe is known as Model-View-Presenter. The best description I've found so far is in Robert Martin's "Agile Principles, Patterns and Practices in c#".

Second, you don't need events for MVP. The idea is that the presenter and view has references to each other and know their interfaces so that data requests/updates are called directly.

Third, the pattern could be cumbersome for an unexperienced developer. The benefits are that the view can be replaced with a fake view so you can easily unit test your presenters. However, an anemic approach, where view and presenter are merged in one class, could probably be simpler if this is your start with oop.

Answer 3

You've kind of got it backwards. One of the principle lessons of MVC (vs something like WebForms) is that there AREN'T any 'events' in a web app. All you have is the HTTP spec, which defines transactions between the client and the server as GET/POST (and less commonly, PUT/DELETE). There is not such thing as a "button click" in MVC. Instead, you have an HTTP POST that came from a form on a page.

Furthermore, every HTTP request is completely disconnected from the ones that came before it, and there's not really a good way to keep a connection open between the client and the server. All the server can really do is accept a request and then render the appropriate response. All attempts to obfuscate this disconnected reality have lead to weaker web frameworks, not better ones.

The various MVC frameworks primarily do what is called "Model Binding". An HTTP POST or GET doesn't come with "objects" constructed from classes; all it really has are POST or GET variables and headers and such. The Model Binders of the MVC world basically take these simple parameters and construct objects from them on the fly, based on what the expected Class Type should be (usually defined in the controller, or by convention). The Controller then allow you to perform code actions based on these objects, and to eventually send back down a response, in the form of a View.

Rather than re-invent the wheel with your own framework at this point, you should pick 1-2 popular MVC frameworks and learn their paradigms. I happen to work in ASP.NET MVC and love it, but Ruby on Rails is very good at well. There's probably 1-2 mature, dependable MVC frameworks for every major language out there, so you should probably start with one that uses a language you are familiar with.

After you familiarize yourself with an existing MVC framework, then you can start to think about how you might have implemented it differently, if that's what you are after ultimately.