Building an application is a long and complex process, which requires careful planning, problem-solving, and a lot of flexibility. By incorporating the use of software design patterns, such as MVC (Model-View-Controller) in your building process, you have general and reusable solutions that you can use to solve commonly occurring problems.

What will the result that you are aiming for look like? What kind of tools could suit the application’s requirements? How is the data going to flow between various layers, or what should (or should not) happen when the user interacts with your application? There are seemingly infinite aspects to tackle.

Surely, you as a developer have realized that already.

In the entire history of software development, one of the most common blunders is not assessing the application requirements correctly – and yet still trying to create the application in the hope that everything just falls perfectly into place on their own (which most likely won’t happen).

Luckily though, many developers have been and still are successful in creating beautiful and smooth applications. And those are the same people that help other developers decode the standards – the design principles – to stick by. By adhering to these design principles, you can avoid quite a handful of common mistakes that may occur during development.

One of those core design principles that comes in handy is the separation of concerns.

Understanding separation of concerns

The design principle in its core is, first and foremost, about order. Separation of concerns ensures that the different handlers in your code are made independent from each other. This comes with various advantages:

• In case of an update to your application, you will only have to change code directly related to the new features, which results in less code to change overall
• You are more likely able to swap in a new implementation without having to fully understand or manipulate the rest of the program
• You will have an easier time finding out, which code you need to change
• You reduce the possibility of breaking code in unrelated features by splitting up the concerns

Based on this principle, as well as on the principle of reusability, several software design patterns are created.

What are design patterns?

A software design pattern is a reusable, general-purpose solution that has been figured out and shared by developers, who faced a similar kind of problem before. This pattern can be applied to help solving the problem at hand. Note, that this is not the solution itself, but rather an approach, a template to follow, which leads to the solution – a formalized best practice.

Again, there are several design patterns, each for different sets of problems. That means, you do not have to (and should not) apply a public favorite pattern to your application, since your personal app development needs might differ.

One of the most popular design patterns, especially in web development, is the MVC pattern, which was first introduced by Trygve Reenskaug, who proposed it as a solution to develop desktop application GUIs. Today, this pattern is widely popular with modern web applications, as it allow the app to be scalable, maintainable, and easy to expand.

Of course, MVC can be applied to different software development problems, but for the sake of narrowing it down and keeping it simple, we are going to focus on its applicability in the development of web applications.

MVC – Model, View, Controller

On a web application, the user sits at the client-side and interacts with the available User Interface (UI). That UI is part of the View layer. Therefore, you could say that the user interacts with View.

View

This layer handles the presentation part of the web app, representing the frontend, or UI. But even the presentation requires some content or data, which in most applications is dynamic.

So, while the View layer needs dynamic data to work with, it is not responsible to create, update, or handle the data. Instead, its job is to decide on the structure and layout of the content – remember the separation of concerns?

For that reason, some other layer has to take on the responsibility of storing, updating, and deleting the data. And this is where the Model layer comes into play.

Model

The Model serves as the backend of the MVC pattern, and is responsible for data handling, state management, and domain logic.

The „data“, in this case could be product details, or a customer’s credentials stored in the database. The state could be the current authentication state of a user, which is also a type of data, but not necessarily stored in the database for the sake of performance. Lastly, the domain logic could, for example, decide how a particular piece of data (like a valid email address) is going to look like.

Some people confuse the Model layer with a simple database, which is not the case because – as we said before – state management is not exclusively done at the database side.

The View layer needs the data, the Model layer has the data. But how do we achieve a flow of data between these two? A third layer is needed to carry the data back and forth. And that job is done by the Controller.

Controller

The Controller can be seen as the brains of the application – controlling and deciding, how data is displayed. It serves as mediator between the View and Model layers, ensuring that the data flows in a request-response fashion.

Whenever the controller receives an action from the view – which is usually the outcome of a user interacting with the View’s UI – it orders the Model layer to manipulate its data by either changing its existing data, or by fetching the controller some new data.

But, although the controller is usually responsible for the mediation between View and Model, this is not always the case in modern implementations of most web applications.

The state management, for example, is done through direct communication between the View and Model. Of course, if the state is stored in the database, the Controller has to take charge. But nowadays, state management usually is purely kept on the client-side in order to ensure the scalability of applications.

What to keep in mind

Again, there is no universal design pattern, since every problem comes in different shapes and sizes. This goes for MCV, too: even though MVC is famous in the community, it has its own set of drawbacks – the major one being, it is too generalized.

Moreover, a simple web application, such as one that just hosts a color picker game, only needs state management, not heavy database implementation. So, if you were to use the MVC pattern in such a simple scenario, it would be way too much and unnecessary.

To wrap it up

Now, we have talked about how following design principles makes your life easier, and why it is helpful to make use of software design patterns. You now know that the design patterns we use today, are all based on design principles, like SoC and Reusability.

We clarified the three elements of MVC:

• Model (backend data handler)
• View (frontend presentation side)
• Controller (mediation between layers)

Lastly, we have concluded that design patterns like MVC are best suited for more complex websites, and would be rather unnecessary for pages that don’t require a huge database implementation.

If you have any further questions regarding the use of MVC, or software design patterns in general, feel free to ask us – we are always happy to help. Also, if you are already working on a project, and are looking for someone to support you in designing, developing, or improving your application, get in touch with us. We would love to discuss your project with you.