> For the complete documentation index, see [llms.txt](https://ios-course.cornellappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ios-course.cornellappdev.com/resources/textbook/mvc-+-navigation-+-delegation/mvc.md).

# MVC

In the previous chapter, we learned *what* views are and *how* to create views in UIKit. We also learned how to use AutoLayout to position our views on the screen. However, our views contained hard coded data and did not have any functionality at all. When we create apps, we want our views to respond and update to user interactions.

**MVC (Model-View-Controller)** is a ***software design pattern*** which is a set of rules that govern the architecture that we follow when writing our code. There are other design patterns out there such as MVVM (Model-View-ViewModel) but we will be using MVC throughout this course. To better understand MVC, let’s take a deeper look at each component.

### Model

**Models** are objects that represent our application’s data. Let’s look at an app we are familiar with, **Eatery**. The models in **Eatery** are the dining halls, the dishes and food items, the user’s information, etc. In other words, models contain information about our application and are often updated based on user interaction or from a backend service.

#### Classes vs Structs

Notice that we often use structs instead of classes when representing our models. The difference between these two is that structs are *value* *types* whereas classes are *reference* *types*. What this means is that if we were to change a property of an instance of a struct, the entire instance changes. On the other hand, if we change a property of an instance of a class, the instance does not change.

For example, consider a `User` model with the property `name`. For a class object (reference type), if we changed the value of `name`, all locations that have a reference to that object have the new updated value for `name`. If this were to be a struct object (value type), changing the value of `name` in one location DOES NOT update other locations because a new instance is being created. We can think of reference types as sharing a Google Doc with other collaborators. If one person were to change something on their side, the others would be able to see those changes. For structs, we can think of it as making a copy of the Google Doc.

One advantage of using a class is inheritance. In other words, we can use properties and methods already defined by a parent class, commonly seen in UIKit. However, there are times when we don't need to use all of these properties and methods, making structs more preferable. This is commonly seen in SwiftUI and why using structs is a lot faster than classes.

### View

**Views** are the visible components that are used to build the user interface (UI). This includes buttons, labels, images, etc. In **Eatery**, *everything* we see is a view. For example, the name of the dining hall is a UILabel which contains information from the dining hall model. We don’t see models. We see views that contain information from the models.

### **Controller**

**Controllers** belong in the middle between models and views. The main goal of a controller is to establish a connection between models and views. The controller is also in charge of processing the logic to update the models and views. For example, in **Eatery**, there is a User model that represents the logged in user. When we sign in, we are interacting with views. How does the model update based on what we passed into the text field? Well the controller handles that logic. If we provided the correct credentials, it will modify the models and update the views such as showing a logout button. If we provided invalid credentials, then the controller will still update the view and show a red error message.

### Putting everything together

One important thing to keep note of is that views and models are separate. They cannot directly interact with each other, but rather, they must go through a controller to make that connection.

We can think of MVC as watching television: the TV is the view, the remote is the controller, and the channels/content is the model. How does the TV (view) change the channel (model)? It can’t! We must use a remote (controller) in order to do that. When we change channels using the remote, we made changes to the model and tell the TV to update its view.

<figure><img src="/files/qNiPwlAACsVQuliQWCm1" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ios-course.cornellappdev.com/resources/textbook/mvc-+-navigation-+-delegation/mvc.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.