MVP Arquitecture in Unity

Lalo Berro
4 min readNov 6, 2022

--

Introduction

MVP (Model View Presenter) its an arquitecture pattern, this means that it gives us a structure to organize our software and increase the scalalability and maintenance of the project. In this article I’m going to explain one of many implementation of MVP and the one I think is the most useful.

What is the porpouse of this arquitecture?

Implement MVP help us to focus more in the problem and less on the organization, also is useful for separate the Busssiness Rules/Domain of the way that is drawn the program. Secondly implement this create a effcient communications between the team members because everyone is talking in the same language and the barrier for understand the another code is smaller.

¿What is Bussines Rules/Domain?

This is where the core a our program is contained, here it is all the logic that resolve the problem and dont have dependendies with external apis.

For example in a Login System our Domain is everything that has to do with trying to login:

  • Check correct password.
  • Check if the user exists.
  • Make a call to the data base.

And this are the elements that are out of the domain:

  • The input field where the user put his Username.
  • Make click on the login button.
  • A loading bar.

Dependency Rule

In this MVP implementation I decide to apply the Dependecy Rule principle (DR).

The DR establish that the communication between layers only has one direction, like in the top diagram the arrow only has one direction, for example the View only knows the Presenter and the Presenter only knows the Model. When we apply this we are implementing the Dependency Inversion Principle (DI).

Boundaries

If can’t communicate the Presenter with the View beacause the Presenter dont know the View, so for solve this we have to apply the DI, fisrt we have to create a Interface called IView that belong to the Presenter Layer then we can use this in the Presenter Layer and implement the Interface in the View Layer.

This is known as boundary and is the interaction the layers between an interface.

Later we will see how to apply this correctly.

Layers

MVP is divided in 3 pricipal layers and 1 optional:

  • View.
  • Presenter.
  • Model.
  • Installer (Optional).

View

This layer is in charge of show/draw the dates and receive user inputs. This doesn’t contain any logic and is the only one who can inherit from monobehaviour.

The View will contain reference to objects that have a connection with the user, like a button, a text, a slider, etc; in the most of cases its relationed with the UI.

This layer only knows the Presenter.

Presenter

Is in charge of receive dates and inputs for the View and give them to the Model and also receive dates for the Model (by DI) to give them a format and give them to the View.

An example of that its a method in the Presenter named SetScore(int score) that is called for the Model that pass the current score, the mission of the Presenter is give it a string format to give it to the View, and then the View put that string on a Text

This layer can contain logic either to format the data or logic necessary for the view, for example to instantiate an object, this is at the discretion of each, from my experience I think it is the best.

This layer knows only the Model layer.

Model

The Model layer is in charge of containing all our business/Domain logic.
Within the model I identify several sub-layers that help to better identify each aspect of the domain:

Entities: Are the representation close to an object, they define the variables and methods that work with these variables, it only contains data that will be used throughout the domain. This layer only communicates with other entities.

UseCase: The UseCase are responsible for containing most of the business logic and where the flow of our program is focused.

Gateways: The Gateways layer is in charge of containing all the implementations that have to do with connections to servers or databases. Mocks are found in this layer, these are “False” or “Substitute” implementations that are in charge of connecting to a fake server or Database, in other words they do not connect to anything but they take the data from the disk itself or from wherever we want, and these serve to be able to do Tests without the need to implement a real server or database.

Installer

The installer layer is responsible for building and initializing our program. It is an optional layer since there are different mechanisms or principles to initialize our program and it depends on each project. Personally, I prefer to take the installers as one more layer and achieve a higher level of organization.

This layer knows all the other layers and breaks with the DY but it is for a greater good. If we do not take this practice as one more layer, it can cause that in a work team that does not have a well-defined class initialization, each programmer initializes them differently.

Example applying MVP in a Login

If you want to see how MVP is applied in a login, check my post: https://medium.com/@laurencioberro/login-example-with-mvp-arquitecture-in-unity-22e4ca86ea9a

I hope this post was helpful to you! and if you have any questions you can comment or send me a mail: LaurencioBerro@gmail.com.

Cheers!

--

--

Lalo Berro

Im Lalo a passionate videogame programmer that loves share quality and advanced content.