For someone not familiar with MVC I'm going to give a quick explanation. MVC is an architectural pattern for programming. As an architectural pattern, it divides the elements into 3 independent groups: Models, Views and Controllers.


In mathematics and computer science, a model is a representation of phenomena. For instance, the same phenomena can be represented through many different models. Consider the following: a falling ball. How do you create a model to present a falling ball? Well, the ball has its current position, as well as velocity, weight and there is gravity being applied to it. So using mathematical notation, a falling can be represented as $latex (p,v, \alpha )$ where $prettyprint lang-csp$ is the position, $latex v$ is the velocity and $latex \alpha $ is a function that makes it fall. Let's start representing this model in a computer:

public struct FallingBall
    public Vector3 velocity; // v
    public Vector3 position; // p

    public void Fall(float timeInterval) // alpha
        position = velocity * timeInterval;

Now, the model does not define only the data, it also defines internal operations that occur on the data. These operations should be independent of external elements and self-contained within the model. For our falling ball example, we know it falls (duh!). In the mathematical model it is represented by $latex \alpha$, in the computer representation it the Fall method.

Now, one thing I find important to say is that the model is just a way to represent things. The things itself are the data. In mathematics, the model is the definition and the data are values assigned to these definitions. In a computer, the models are the classes/structures and the data are the instances.


The View em MVC is used for the visual elements. It does not operate on the data, but it reads the data from the model and show it on screen. Also, the user does not interact with the View, so it is kind of an end-point of the system. Think about a table. The model being the columns, the data being the lines and the view is simply an excel spreadsheet. We can change the way we visualize the table without changing its data. We can use the same columns and same lines and draw a line graph or a column graph or a table or even just some plain text separated by a comma. These are all different views of the same model.


Now, this is where the fun starts. While the model defines what is a thing the behaviour for these things, it does not exactly define when they happen (when should the ball fall?) and while the view shows us the things, it does not change them. This is where the controller comes. Since we can interact with a computer, the views can receive user inputs (buttons, clicks, touches, etc...). These inputs are redirected to controllers, which in turn invoke model behaviours or create views or change the view or basically control the flow of the application.

As an example, think about a website (this is where the MVC pattern is most used). The model is the database design, the data is the database entries, the view is the webpage and the controller is the code on the web page that calls functions or send requests. We can have the controller showing up new views (such as popups) or update the data in the database when you click a button or any other stuff.

That is pretty much it. Recently the MVC pattern has been more used in game development as games are also applications with a user interface.


Popular posts from this blog

Unity3D/C# - Asynchronous Programming - Coroutines vs await/async

C# - Simple Graph Interfaces and a MeshGraph

Tools and Property Drawers