- Model- Handles data and “business logic”/data related logic
e.g. A Customer object will get the customer information from a database, manipulate it and update the data back in the database or use it to render something.
- View- Handles the UI logic of the application
e.g. The Customer view would include the UI components like text boxes or whatever the final user interacts with.
- Controller- Handles the application logic and interactions between the View and Model.
e.g. The Controller gets an input from the users in the View, then process that input with the help of the Model and which then passes the result back to the View.
Why use MVC?
Why’re we even using MVC? Well, because of the separation of responsibilities, future changes can be made easier, and the scalability of the app is increased. Multiple developers would be able to work on any part at the same time. It has “low coupling” among the models/views/controllers, which just means that each component doesn’t necessarily need to know about the other components.
In our case, we’d be using the Ruby on Rails web framework with this MVC pattern.
Models
ActiveRecord is what we’ll use as our model in MVC.
ActiveRecord is responsible for handling everything related to the database. It establishes a connection to the server, retrieves data, and stores new data.
Views
The views should contain presentational logic only. The code in a view should only be handling displaying pages in an app. Everything sent to the user’s browser is handled by the view.
Controllers
Not too sure how these work yet since we’re not using Rails, but this handles the app logic of our program. This is what allows interaction between the browser/user and the data.
Recap
So, to recap, a user’s request would be processed like:
- The browser sends a request for a page to the Controller
- The Controller takes the data it needs from the Model
- The Controller gives the data to the view
- The View is rendered and sent back to the user’s browser to display
