Model, View, Controller (MVC)

I’ve spent a few days from the past couple weeks refactoring SNES Tracker Debugger (STD), and I quickly learned that my GUI code was bit tied in with the application logic. I came across a real winner, as far as an architecture – MVC. My implementation of MVC is custom in that it may vary from “official” descriptions. There may even be a different name for paradigm I have created from MVC. Offhand, here are some distinctions of my impl of MVC from the “traditional” description

No intent to connect models to views (but I may contradict if sensical to do so)

Views have their own GUI Logic (since this is not a webpage but a desktop app)

so let’s focus on what I imagine.

Model

This simply refers to the “data.” This is the least well-defined of the three entities. It is also intended (in my implementation) to be out of direct-contact with the View. However, I have given myself permission to make exception(s) if necessary, based on the on-going experience of creating this architecture in practice. (1)

View

The GUI components are now designed completely independent of the internal logic/data. They access the “internal” data and logic through controllers which expose APIs.

Controller

This is where the API functions and control logic reside. The core idea is that a controller will present an API to the View, typically representing one or many CRUD-like operations.

OK, that was a very vague description though (perhaps we could call it language-agnostic). So let’s start imagining the components in the language of CPP

CPP MVC Paradigm

There are some potential helper “things” I can use to spur development of this kind. These ideas were extrapolated from http://stackoverflow.com/questions/6929957/mvc-approach-with-c

boost state machines for the logic and boost signals to connect things together.

CPPInject

I am rather unclear on what I might use. So, let’s just talk conceptually.

Views

I plan on all GUI code to be a part of this “VIEW” sub-component .. There are different types of Views (not exhaustive)

One that will need data from a controller

One that will need data from a controller, and will update new data to the controller

One that needs no connection to a controller (unlikely?)

Of course, views can have their own internal logic to manage themselves. I anticipate a view that updates another part of itself based on certain internal state. This is normal, any GUI logic is simply part of the View.

It is here that a part of me wonders whether that kind of logic should be outside of View … But for my purposes I think it’s a good architecture to have all GUI logic separate, in what I will call the “View” or GUI code, and I think it’s OK for them to maintain their own state.

Controllers

I don’t understand yet how I will be connecting views to controllers in a CPP manner, but a View class might be able to “target” or “include” any number of specific controllers from its class definition. This might be from reference(s) passed to the View’s constructor, or via composition.

Models

This might best be considered as a mixture of data structures and “internal API.” Generally speaking, I intend on seeing only the controllers acting on this data.

Now I want to encapsulate this entire MVC paradigm within an Abstraction Layer for Video / Audio / Input (Keyboard, MIDI, ?)

Footnotes

(1) I initially thought “Direct” memory access could be beneficial for APU RAM access, for instance — but even so, I imagine an API will be better simply because different APU functions are necessary to modify different portions of the RAM … We’ll see…