How does the interaction between layers in C# work and what is the function of each one?

Question:

Assuming a project with these layers: DAL , Controller , Negocio , Model and View

I'm trying to learn C# looking at ready-made project code, but I still don't quite understand the correct order of creation and their dependence on each other.

I would like to know how this gear works. I realize that if I forget a piece it won't work, so I would like to know what each of these layers is for.

Could someone give me a brief explanation?

Answer:

I'll try to help (hopefully not cause more fragmentation – each answer here is saying subtly different things).

Summary: The question seems to refer to the MVC architecture: it talks about Controller, Model and View. It presents the DAL and Business as distinct layers and at the same level as the first 3 (which is a little misleading, but more on that below). That said, I will try to explain what MVC is, after all, and how these 3 layers are related.

First, I will use the terms Model , Controller and Vision (after all, we are in the Portuguese OS).

Second, MVC isn't a term restricted to .NET, let alone C#: it's actually an architectural pattern that's been around for decades , one that was used long before the popularization of the Web (it was created in the 1970s by the folks at Smalltalk)! On the other hand, the ASP.NET MVC framework follows the MVC architecture (so what is true for the latter is generally also true for the former).

Thirdly, I think it's important to start by defining the layer that is by far the most controversial: the Model .

Translating what is in the Wikipedia entry Model-view-controller into English, we find the following sentence:

The central component, the model, consists of application data, business rules , logic and functions.

The fact that the term "model" is used indiscriminately, meaning either an Active-Record (for example, by the Ruby on Rails community), or a DAL or a mere DTO (by the ASP.NET MVC community itself) doesn't help.

So let's stop messing around: Model is not only the name of an entire layer (not the name of a class type, or a specific design-pattern), but it's also often the largest layer in any system. Self-respecting MVC! In fact, this is exactly why it is usually divided into sub-layers: access to data, services and so on. (However, this is not described in the MVC architecture, even though it is often recommended).

Editing Trying to explain it in a slightly less "radical" way: specifically in the ASP.NET MVC world, it is customary to give the nickname "model" (the most appropriate name for this type of class is "View Model ") to classes used to transport data between the controller and the view. And here is the question: is model a class or a layer? Well, in the same way that "Rio de Janeiro" is a term that depends on context (it can refer to the city or state), "model" too. Formally speaking, this term refers to the entire layer, but it can, in principle, be used to refer to any class belonging to it. In other words, a domain class or an entity, even though they are not "view models", are also "models".

And now let's define the other MVC layers:

  • The Controller is the layer responsible for the presentation rules, and for transforming data between the Model and the View . And pay attention: presentation rules != business rules!
  • The View is the layer responsible for presenting the data to the end user (it can still be divided between passive and active , but that is beyond the scope of this answer).

The main advantages of the MVC architecture are, in my view, the decoupling between presentation needs and business rules, the ease of using TDD techniques and the practicality in introducing new representations of the same data (the three concepts, by the way, are closely related).

In practice, some examples of the advantages of using MVC:

  • It is possible to create several different Views, representing the same data source (for example, presenting data in the form of a detailed listing, or in the form of a graph, or merely as a JSON package – in ASP.NET MVC you would need to create a new one action in the Controller for each of these alternatives, but other MVC libraries can only allow this by adding a new View).
  • Business rules become independent of presentation needs – they could even be maintained by a separate team. If changes occur to some business object (for example, the name and type of a field in a returned DTO), the impact is minimized: in principle only the Controller (which transforms the data for the consumption of Views) would need to be changed .
  • It becomes possible to test each layer independently: I can connect my Views to Test Controllers (which don't consult the database and use fake data, for example) to check if the presentation is adequate; I can also directly call a Controller's methods from a unit test suite, without rendering any View, and so on.

Edition

The OP also refers to two other layers, DAL and Business, which are not described by the MVC architecture, but which need to be explained as well:

  • DAL: Data Access Layer, or Data Access Layer. Typically they are represented in the form of classes that encapsulate SQL queries, or calls to some ORM library (such as Entity Framework, NHibernate and Linq to SQL, in the case of .NET).
  • [Layer of] Business: Classes of service, which expose data obtained from the DAL to the higher layers, usually in the form of DTOs.

As I said above, from the MVC architecture point of view they are "sub-layers", belonging to the Model (but this does not make them any less important, on the contrary).

Note: When both the Business and DAL layers are present (and only in this case), the former normally acts as a gateway to the latter. In other words, the DAL layer is only accessed by the Business Layer.

I'm not always required to have these two layers:

  • In MVC applications for simple CRUD, where you only want to consult, insert, edit and delete data, it doesn't make sense to have a Business Layer. For these cases, Model = DAL (and this is, I imagine, where the so common conceptual error I referred to above comes from).

  • In MVC applications without persistence, it doesn't make sense to have a DAL. In this other case, Model = Business Layer (a typical example of this type of application is a calculator – the Business Layer would be represented by the variables and functions needed to perform the calculations).

Even in these "atypical" cases, the architecture is still MVC.

And that's it! Hope this helps.

Scroll to Top