How to do MVC in C++

Question

I have a QT application with a window of OSG written in C++. I want to implement the app using MVC design. The application allows you to add markers to OSG model and it is using QT to edit the markers.

First, I want to make sure that I understand MVC right.

• Model - it's just the data that the View need to view and the Controller change. It is just a struct or POCO.

• Controller - is where all the logic of the app.

• View - need to view the Model data and send output to the Controller. Am I right? Everybody is explaining MVC differently.

How I do MVC in C++:

Instead of using callback for input I use the controller with the interface like that:

class InputCallbacks {
public:
    virtual void undo() = 0;
    virtual void redo() = 0;
    virtual void addMarker(Posstion postion) = 0;
    virtual void removeMarker(Marker marker) = 0;
};

class Controller : InputCallbacks {
    /// ...
};

class View {
public:
    void addInputListener(InputCallbacks* controller)
    {
        contollers.add(controller);
        // ...
    }

    void refresh(Model* model)
    {
        // ...
    }

private:
    List<InputCallbacks*> contollers;
    
    
    // example of View input to Contoller
    void onUserClickUndoButton()
    {
        for (auto contoller : contollers)
        {
            contoller.undo();
        }
    }
};

Is this MVC design? Or I should do one callback that gets the state class, that is an interface? What is the way to make an MVC design in C++?

Answer 1

IMHO a pretty correct statement in the question is this:

Everybody is explaining MVC differently.

The reason behind this is that today there is not 100% consensus among software engineers what exactly counts as MVC, and what not. So as long as your program has model classes, which are unaware of the views, and view classes exclusively responsible for the user interfaces, and maybe a controller which does coordination and communication between the former, a design can be called a variant of MVC.

Model - it's just the data that the View need to view and the Controller change. It is just a struct or POCO.

No, that's missing the point of the model. Model classes contain usually more than just "dumb data". They contain lots of the application logic, especially view independent logic which is centered around the specific model object. That's why in context's like DDD, it is also called "domain model" - model classes contain domain logic.

Controller - is where all the logic of the app

Nope, see former paragraph. In lots of MVC variants, controllers are only responsible for communicating between the view and the model, maybe in one, maybe in both directions. Other variants allow more logic to be placed there.

View - need to view the Model data and send output to the Controller.

Yes, and probably more. The view will also get input from a user, as well as input from controllers. There are MVC variants with absolutly no "logic", not even pure UI logic, inside the view, and variants with some kind of "UI controller" a.k.a "Presenter" holding the UI logic.

Is this [ .. code above ..] MVC design?

Well, sort of, given the fact there are many designs which can count as "MVC". In your code example, the view is related to several controllers. That's a little bit unusual, but not forbidden. This design requires some "logic" inside onUserClickUndoButton() which iterates over all controllers. That is probably ok - introducing a separate class just for refactoring this loop to a place outside the UI will probably not be worth it.

Let me add a final note: IMHO the question you should ask, however, is not "is this MVC"? You should ask yourself if this kind of design (or this variant of MVC) is what helps you most to give your application a maintainable, testable and evolvable structure. That is way more important than whether your design matches a certain name, or not.