Hey folks! If you’ve been following the challenge I made, you know I’m trying to learn MVC. In my last app, I rewrote the project using MVC and something like this came to my mind. I decided to write what I learned. Since I haven’t shared anything on my blog for a long time, you are reading this article right now. Let’s start then.
What is a Design Pattern?
First, let’s talk about what a design pattern is. We want to ensure code reusability. (By the way, we are developers.) We want to produce standardized solutions to the problems that may arise in software that every software developer can understand. The system we use for this is called the design pattern. It seems a little confusing at first. Let’s simplify it.
Design patterns help us better organize and structure the code we write. Let’s say we have written all the code in our project in viewController. (As I did, please don’t.) And consider that our application is getting more and more complex. Right now, yes, you can understand the code you wrote, but when you go back a few months later, you probably won’t be able to understand that code. For a more complex app, this is why we need to use design patterns.
So which design pattern are we going to use, which is a question that comes to mind. Depending on the app we are writing, we may need to use different design patterns. We’re going to talk about MVC.
So what is MVC?
The model view controller is used to increase code readability and to ensure that the project has a modular structure. MVC stands for the model view controller. So let’s say we split the project into three parts.
We have a model, view, and controller. Let’s look at these concepts now.
Model
We keep the data we will use in the project in the Model. Let’s say we have a Quiz app. What are the most necessary data in the Quiz app? Of course questions. For example, we may keep information about these questions here.
View
The view is actually the UI. That is the part where the user interacts.
Controller
All controls in the project take place here. The controller also controls the flow between model and view.
So how exactly does this work?
Let’s assume that our user interacts with the application, that is, any action is taken on the screen. In this case, information about these actions goes from the view component to the controller. Then the Controller will interpret this information and request some data in the model. The model will process the data using its business logic and the processed data will be sent back to the controller. It’s actually simple, isn’t it?
In the last step, the controller interprets this data and sends it to the user interface. The view and the model never directly talk to each other, and it’s only through the controller that they’re able to interact.
If we schematize it, this is exactly what I’m talking about:
This will also reduce errors and make the code easier for other programmers familiar with the MVC design pattern to understand.
To see this on a project, I’ll add a GitHub repo here.
I guess that’s all I have to say, see you soon!
