Model-View-Controller (MVC) is an extremely useful software design pattern. It works well in web applications, allowing you to build structure in separate layers. This chapter introduces the MVC pattern and walks you through installing and setting up Ember, a framework for MVC. The next few chapters focus on individual pieces of the pattern as you create a new application layer by layer.
There are many interpretations of MVC, especially in the front-end world. Figure 19.1 shows the interpretation we will use.
Here is a breakdown of what each layer does:
-
Models manage data. When data changes, the model tells anyone who is listening.
-
Views manage the user interface. They handle the presentation of models and listen for any changes. Also, when UI events fire in response to user input, they call handler functions in the controller.
-
Controllers hold application logic. They retrieve model instances and give them to views. They also contain handler functions that make changes to model instances.
If this seems circular, it is. The three pieces work together. Application data flows from the models to the view. Event data flows from the view to the controller. Controllers trigger data changes in the model based on UI events.
You may be wondering how, then, you get into the circular pattern of MVC. In Chapter 8, you created the CoffeeRun application and enclosed all the functionality you needed in the Window.App object. Each added module had a specific role in the application and was named for its functionality. The MVC pattern needs an initial set-up function, like creating a new Truck, to load controllers. Controllers, in turn, load models and views.
Your next application, called Tracker, will load an initial DOM state in an HTML file as only an empty <body> tag. The scripts to initialize your application will be loaded from this HTML file as well. In the MVC pattern, views (HTML content) are dynamically rendered depending on the route and state of the data (models).
The application you are going to build will require more than CoffeeRun’s seven modules. The MVC pattern helps you break up modules into functionality-specific files and maintain consistent organization – whether you have a dozen modules or a hundred.
Your Tracker application will include URL routing, one of the best features of web applications. It will have models to define the data, controllers to handle user actions, templates to define the UI, and routes to assign the models to the templates. As you build the application, you will pick up some new patterns and techniques that will make your code lightweight and elegant.
Your customer for the Tracker application is a cryptozoologist, traveling the world in search of animals like Bigfoot, chupacabras, the Loch Ness Monster, and unicorns. This client wants an app for tracking these mysterious creatures and recording information about any sightings. The requirements may change (and they usually do), but to begin with the user should be able to:
-
list existing sightings
-
add new sightings
-
link creatures to sightings
-
see the latest sightings via flash messages
Each sighting should have the following model data and associations:
| Sighting model attribute | Attribute type |
|---|---|
| date creature was seen | date object |
| location | string |
| creature | creature model key |
| witness(es) | array of witness keys |
Each creature should have the following model data:
| Creature model attribute | Attribute type |
|---|---|
| name | string |
| type | string |
| image path | string |
And each witness should have the following model data and associations:
| Witness model attribute | Attribute type |
|---|---|
| first name | string |
| last name | string |
| full name | string: concatenation of first name and last name |
| string | |
| sighting(s) | array of sighting keys |
Building Tracker will be slightly different than building the previous applications in this book. It will more closely resemble real-world application development. There will be more code in sections and less instant feedback. However, you will get a realistic sense of app development and will build a satisfyingly complex app (Figure 19.2).
