Layered Architectures

Before understanding the reasons behind the creation and adoption of the MVC pattern, we need to understand how and why a well-structured application is organized in layers. The next section is dedicated to a short summary of layered architectures. Next, we will analyze the MVC pattern and its ASP.NET Core implementation in detail.

The different activities of a web application

All business applications, and, in general, all non-trivial web applications, perform three kinds of activities:

1. Interacting with the user to take their inputs and to return results. This activity is called Presentation.

2. Performing business-specific processing on data. For instance, a personnel management application computes salaries taxes, etc., while an E-Commerce application computes prices, discounts, and delivery plans. This activity is called Business.

3. Storing and retrieving information from long-term storage. This activity is assigned the Data label.

Since the above three activities involve different technologies, tools, and libraries it is strategic to make the code-base of each of them independent from the others. This goal can be achieved only by organizing the three code-bases into separate modules that communicate through well-defined interfaces.

This way, we may replace each module with a completely different implementation without affecting the remainder of the system. For instance, we might decide to migrate from one Cloud provider to another and use a different permanent storage engine by simply rewriting the third module that manages the permanent storage and without affecting the other two modules.

However, the three modules perform conceptually different operations, with different design and requirements-gathering techniques, so, in complex applications, it is not easy to coordinate them. More specifically:

1. The Data module contains knowledge that is specific to the chosen storage engine type and supplier. That is, how to filter data, how data consistency is achieved, and so on. The format of the data retrieved is specific to the chosen storage engine type and supplier. As a result, this format must be translated into a neutral format in order to achieve independence from the storage engine.

2. The Business module, instead, speaks the language of the domain experts, and encodes their knowledge. For example, in a personnel management application, the business module encodes the knowledge of personnel experts, so classes, properties, and methods will have names taken from the domain of personnel management.

3. Finally, the Presentation module will use a different language, the language of users. This language differs from the domain expert language used in the business module since users usually are not experts of the application domain but have different roles and different needs.

As a result, when designing each of the three modules above, we must extract requirements and knowledge from completely different sources that speak completely different languages. Now, the only way to have effective communication during the requirements gathering stage is to have each software module adopt the same language of the people or source of information. Therefore, the applications will be made of modules that adopt three different languages. This means different classes, interfaces, properties, and method names, and conceptually different error messages. Therefore, a translation is needed each time a module communicates with another.

Layered architectures

The so-called layered architectures were conceived simultaneously to solve the problem of module independence and language translation. They propose further constraints on how the three modules are organized. More specifically, they call each of the modules a Layer, order them in a sequence, and propose that each Layer might communicate just with the layer that immediately precedes it. The diagram shows the layered architecture organization: