“Hours of work saves minutes of planning.” —Unknown

The MVC pattern

The Model, View, Controller (MVC) architecture is a powerful way to simplify most applications by separating it into smaller parts, each with a single purpose.

Read this short explanation: “MVC: Model, View, Controller”, by Code Academy

By using this method of organizing your code, you can develop the different parts separately.

Model

The Model is the code that stores and retrieves data from your data store (e.g., database or file system). It’s not the data itself, but rather an object that holds the data. In the sample code, this is done in Python.

Each model represents an entity in the database. An instance of a model represents a row in the related database table. Thus, models talk to databases. Models don’t have significant business logic, but they might have some logic to manage relationships between entities. For example, a Student might have a fetchEnrolledSections() method, or an enrollInSection(section) method.

View

The View is the content the user sees. The sample code uses HTML as crafted with Jinja templates. (All of the stuff in the “Templates” folder.) Views accept model objects (as assigned by the Controller), apply needed templates, and provide an interface for the user to interact with the application.

Controller

The Controller handles the user’s actions, and connects the View and the Model. If the user clicks something in the View, that action is sent to the Controller. The Controller makes changes to the model, if needed. In the sample code, each method in flask_app.py is a Controller.

Controllers implement business logic. The steps in your use case description or sequence diagram should roughly reflect lines of code in your controller.

Controllers talk to both models and views. Controllers never talk directly to databases. Keeping this modularity should keep your code simple.

Taking the time to understand how the Sushi Sample Project works will save you hours of development time later.

Thoughts on Models and Controllers

How many controllers should you have? It depends. (You knew that answer had to be somewhere!) Although some applications might have a controller for each model, it’s more common to have a controller for each process or collection of related processes. This often matches up to one per model, as processes are in place to create and modify entities in common ways, but it’s not necessarily 1:1. Especially for smaller projects, you might consider a controller (or at the very least, a method) for each use case as a starting point.