Application Architecture: ASP.NET MVC Programmer's View
Hello. A few months ago I was tormented by the question of how to design my application correctly, so that later it would not be disgusting to look into my code. Then I decided to delve into this issue and after a whole day of searching, I realized everything. Finally I decided to share my knowledge, maybe they will help someone, and maybe not. In general, read.
• Data Access Layer or DAL
Receives or modifies data directly from the database or via ORM. Data is filtered, but not processed. It is also possible to obtain data from other sources, for example through the parsing of pages.
• Business layer or BLL
Works with data via DAL. Data is processed and brought to the desired form. This is the most interesting layer. This is where all the application logic happens.
• Layer Services or SL
This layer is found only in large applications. In essence, this is an API interface for accessing an application from other applications. This layer will not be described, due to my extreme ignorance in this area.
• presentation layer or PL
Actually data presentation layer. It processes data from BLL into the necessary to represent the entity.
As we already know, the presentation layer is used to convert the data into the format needed for display. An application with the same logic can have different formats. Normal software, that is, a windowing application, has other classes to display than the web or console project. For each type of application there must be a class pack from PL. In the case of an MVC project, this is a set of controllers. In web projects, controllers also have the right to control the routing, although at first glance this may seem to be inappropriate for controllers, it is unacceptable to place it on the BLL layer.
')
The business layer is needed to hide the entire business logic of the current application, and, as the application platform can be of any kind, or the application data can be from any source. This layer transforms logically related entities into one concept. Suppose there is a task to make a forum and you need to display all messages from the user in his office, and it doesn't matter if this is an answer or a topic. These entities are converted to the message entity. Transforming database entities into logical entities of an application is one of the main responsibilities of the business layer.
The DAL layer is a layer of samples from a database, XML files, API services, etc. For each data source of a company, there should be a separate library of DAL layers, but most often only the database acts as a source.
All of the above helps primarily for large projects that may have different presentation modes, different data sources and different applications with common data. And an ordinary developer may seem to be overkill, because he needs to write a small program, under one platform with a small amount of data, but it only seems that way. In fact, the division into layers gives huge advantages to almost any project. Main advantages: the code looks beautiful, readable, the concepts are not confused and it is easy to expand. Refactoring is facilitated, which is very important for a beautiful application. These rules can be neglected only in small projects and then, if no further improvement is expected.
It seems everything. If something is incomprehensible or incorrectly stated, write in the comments, I will try to fix it. Thanks for attention.
Any abbreviations
• Data Access Layer or DAL
Receives or modifies data directly from the database or via ORM. Data is filtered, but not processed. It is also possible to obtain data from other sources, for example through the parsing of pages.
• Business layer or BLL
Works with data via DAL. Data is processed and brought to the desired form. This is the most interesting layer. This is where all the application logic happens.
• Layer Services or SL
This layer is found only in large applications. In essence, this is an API interface for accessing an application from other applications. This layer will not be described, due to my extreme ignorance in this area.
• presentation layer or PL
Actually data presentation layer. It processes data from BLL into the necessary to represent the entity.
Detailed analysis
As we already know, the presentation layer is used to convert the data into the format needed for display. An application with the same logic can have different formats. Normal software, that is, a windowing application, has other classes to display than the web or console project. For each type of application there must be a class pack from PL. In the case of an MVC project, this is a set of controllers. In web projects, controllers also have the right to control the routing, although at first glance this may seem to be inappropriate for controllers, it is unacceptable to place it on the BLL layer.
')
The business layer is needed to hide the entire business logic of the current application, and, as the application platform can be of any kind, or the application data can be from any source. This layer transforms logically related entities into one concept. Suppose there is a task to make a forum and you need to display all messages from the user in his office, and it doesn't matter if this is an answer or a topic. These entities are converted to the message entity. Transforming database entities into logical entities of an application is one of the main responsibilities of the business layer.
The DAL layer is a layer of samples from a database, XML files, API services, etc. For each data source of a company, there should be a separate library of DAL layers, but most often only the database acts as a source.
All of the above helps primarily for large projects that may have different presentation modes, different data sources and different applications with common data. And an ordinary developer may seem to be overkill, because he needs to write a small program, under one platform with a small amount of data, but it only seems that way. In fact, the division into layers gives huge advantages to almost any project. Main advantages: the code looks beautiful, readable, the concepts are not confused and it is easy to expand. Refactoring is facilitated, which is very important for a beautiful application. These rules can be neglected only in small projects and then, if no further improvement is expected.
It seems everything. If something is incomprehensible or incorrectly stated, write in the comments, I will try to fix it. Thanks for attention.
Source: https://habr.com/ru/post/154027/
All Articles