Model View Controller (MVC) is a design pattern. In this video we will talk about MVC in the context of games like chess and tic-tac-toe, implemented in JavaScript and HTML, but the same concepts can be used with many different programming languages for many different kinds of programs.




The model contains application-specific objects (or functions and data) and does not contain any information about how that information will be displayed to the user. For a game of chess, the model would include rules of the game (like how the pieces move) and the state of the game (like the locations of the chess pieces on the board. The model would not have any information about what the board or the pieces look like.

The view displays the state of the game to the players. For chess, that means displaying the chess pieces on the board.

The controller connects the model and the view.

One important advantage of the Model-View-Controller pattern is reusability. Often the model or the view can be reused in other programs. (Controllers are less likely to be reusable.)




Let's look at some of the advantages of using MVC.
• One advantage is reusability. You can use the same model with different views. You can also use one view with different models.
• Another advantage is that using MVC encourages well-defined interfaces between the model, view, and controller.
• A third advantage is localized changes. A change to the view doesn't require a change to the model, and vice versa.
• A fourth advantage is simplicity. Each part is simpler and easier to understand, implement, and test.




Let's look at the game of chess in terms of a model and a view. One way to represent the model for a chess game is to use Forsythe-Edwards Notation (or FEN for short). FEN includes all of the state information for a game, including the positions of all the pieces and which player moves next. The model provides enough information for a chess player to decide on the next move or determine who's winning the game.

Note that the view, or the appearance of the chess set that's being used to play the game, makes no difference at all in deciding which move to make.

This model could be used with any number of different chess sets, or views...




...like this traditional chess set...




...or a more abstract set like this one...




...or a more ornate set...




...or a very large set...




...or any number of other chess sets or images of chess sets, including animated renderings of 3D models.

From the point of view of interior decorating, or making a movie (like the first Harry Potter movie) the appearance of a chess set can be very important, but in terms of chess, the view has absolutely no significance.

By separating the model and the view we can get the advantages of MVC mentioned earlier, such as reusability, better-defined interfaces, localized changes, and simplicity.




There should be NO information about the view in the model. For purposes of this class, that means the model should have no HTML, no CSS, and no images. It's a good idea to put the JavaScript code for the model and the view in separate files so that you can easily look through the model and make sure it doesn't contain any view information.




If the model doesn't have any information about the view, it's much easier to use the model with different views. It also localizes changes so that it's often possible to make changes to the model without changing the view, and vice versa.




Let's look at the game of Tic-Tac-Toe as a simple application for the model-view-controller concept. There are many different ways we could represent a Tic-Tac-Toe board. Suppose we decide to use a two-dimensional array for the board. Let's see what happens when we don't separate the model and the view.




If there's no separation between the model and the view, then when a player clicks on a square, the event handler for the click directly accesses the board data structure and changes it.




If we decide to use a different data structure, like a one-dimensional array, then every line of code that accesses the board data structure

must be changed.




That's a problem, because change is not localized (or confined to a relatively small section of code). Every line of code in the program must be checked to see if it refers to the board data structure. Unless the program is very small, there's a good chance that some changes will be missed or done incorrectly.




Now let's see what happens when we define a model that is separate from the view and define a well-designed interface for the model. As before, we will use a two-dimensional array to represent the Tic-Tac-Toe board.




However, now we will separate the model and the view. By doing so, we will be free to change to a different board representation later, or to make other changes to the model, without having to change the view.




We will make the model a "black box", which means that other parts of the program do not have direct access to the data structures in the model. The only way to access the model is to call methods. That means that if we change the board representation, only the methods will have to change.

The methods that we define will allow other parts of the program to do everything that needs to be done for the game of Tic-Tac without directly accessing the data structures in the model. Deciding what methods the model will provide is a very important step in the design of an application that uses MVC.

In this case, the methods that the model provides are markSquare, getSquare, and isGameOver.




Now let's see what happen when a player

clicks on a square in the Tic-Tac-Toe grid.

The event handler in the view code recognizes the click event,

and gets information about the click, which it passes to the controller.

The controller gets information about the click and determines which method (or methods) in the model need to be called, and what information to pass as parameter values.

In this case, the controller calls the markSquare method

and passes 1 and 2 as the coordinates, and 1 as the player number.

The model then updates the board data structure.

Note that there is no code in the view or controller that depends on the board data structure being a two-dimensional array.

This diagram shows the view and the controller as separate components of the program, but for this class it's okay to think of the view and the controller as a single component of the program. That isn't following the MVC design pattern exactly, but it still gives us a lot of the advantages of using MVC without getting into a lot of details.




Now that we have a model that provides a well-designed interface and is separated from the view and controller, what happens if we decide to change the representation of the board from a two-dimensional array to a one-dimensional array?

Only the code in the model needs to change. The changes are localized to the model and no changes are required in the view or controller.




Suppose that we decide to make a game of Tic-Tac-Toe that runs on a small phone screen that doesn't use HTML, but will be implemented in JavaScript.

We will have to write new view code, but we can reuse the model with no changes.




To summarize, some advantages of the model-view-controller design pattern are reusability, well-defined interfaces, localized changes, and simplicity.
The model should not have any view information or code in it. For a JavaScript web application that means the model should not have any HTML, CSS or image file names in it.
An important part of designing an application that uses MVC is to decide what methods the model will provide.