Dependency injection in .Net Mark Siman 1 - Dependencies between application layers
Dependencies between application layers | Designer implementation, lifetime | Cross-cutting aspects of the application, interception, decorator
The principles of program development, called “Dependency Injection” (OT), is not a new topic, but it’s no less interesting and useful. Even if you do not know what a “dependency injection container” is, you may already be using the OT. Do you work with Angular? - you are in the subject. In any case, it is impossible to ignore this concept and remain a competitive developer.
Let's talk about the wonderful book by Mark Siman. This note does not claim to be complete, it is not a brief summary and can in no way replace Mark's work. But, I hope, motivates to read 379 pages (there are 463 pages in total in the book), it will show interesting techniques from the author’s arsenal. And, of course, it will help support the conversation with colleagues at the water cooler.
The book is very suitable for server-side web developers, development approaches are considered on the example of an online store. Well, if you have experience of participation in real projects, then in the course of the narrative analogies from life will arise - Mark managed to highlight real, uninvented problems and show how to solve them. If you are just starting your career, reading will not be so interesting, you have not yet felt the pain of development and support of any major project.
')
The book is for those who not only want to understand the "dependency injection" (for this there are articles shorter), but more for those who want to learn how to develop long-playing applications that can be developed.
In order to make a good durable project, the code must be structured, broken into modules that are as less related as possible - loosely coupled.
The book is about how to achieve weak binding, including (but not only) using the OT. Linking code can be estimated, there are unambiguous quantitative indicators. For example, how many libraries are in your project, what references to each other do they have. It happened that your ASP.NET MVC project has a dll reference with Entity Framework entities? Or even does not refer, and contains Entity context? Reason to buy a book.
Further reading will require some experience developing web projects. If you do not have it, then it will not be interesting.
Often, there are 3 levels of application:
- display level
- level of business logic
- level of data access
This Mark considers correct, in his opinion, it is possible to go further and divide the display level by two more and be 4.
Usually start with a data access level. And usually use the Entity Framework (EF) (nothing against EF is a great technology).
In articles and books about the Entity Framework, you can find descriptions of how great it is that the Code First model allows you to create domain POCO / DTO objects. How bad it is to use attributes in such POCO objects — binding to database tables should be done only using the Entity Framework Fluent Api. It is advised to have two projects:
- one with POCO objects (describe objects that lie in the database), let's call it Models
- the second one contains EF Context and Fluent mapping to the base, let it be DataAccessLayer
Thus, POCO objects seem to be “disconnected” from the “data access layer”. EF Context plays the role of repository.
In this scheme, it is easy to be deceived. Next, a BusinessLayer project is created in which:
- EF POCO objects are used as business entities (after all, they are “not connected in any way” with the database),
- EF Context is also used, linq queries are very convenient.
Thus, the BusinessLayer project contains references to Models and DataAccessLayer projects .
The display level queue is an ASP.NET MVC WebSite project that renders EF POCO objects. WebSite project has references on BusinessLayer and Models .
The scheme of dependencies of such a project in Figure 1. It can be seen that the entire application depends on the level of data access. The result is a strongly related code.
Figure 1. The dependency diagram of a highly related application (arrows in the direction of dependence)
Note: EF POCO objects are not actually business objects, they are one-on-one mapped on the database structure. They cannot be changed without changing the database schema; if the database is changed, you will need to rewrite all linq queries that are made in BusinessLayer .
To determine which dependencies between the layers are correct, Mark argues as follows: which part of the application does not make sense to change even in a hypothetical scenario?
Thus, all application layers should depend only on business logic. The business layer should not have dependencies at all - Fig. 2.
Fig 2. Correct dependency diagram
How will BusinessLayer get data without reference to DataAccessLayer and its repositories? In the book it is.
When examining the example, the author makes an interesting remark: not only the resulting dependencies are wrong, but also the order in which the layers are developed. It is necessary to start not from the database, and not from business objects, but from the display level. In the text you will find a step by step description of the development.
We talked about those to whom the book is addressed, briefly reviewed a typical web application. Mark Siman has cooked a lot more useful. The note turns out long, it makes sense to break it into blocks. Until new meetings.
The principles of program development, called “Dependency Injection” (OT), is not a new topic, but it’s no less interesting and useful. Even if you do not know what a “dependency injection container” is, you may already be using the OT. Do you work with Angular? - you are in the subject. In any case, it is impossible to ignore this concept and remain a competitive developer.Let's talk about the wonderful book by Mark Siman. This note does not claim to be complete, it is not a brief summary and can in no way replace Mark's work. But, I hope, motivates to read 379 pages (there are 463 pages in total in the book), it will show interesting techniques from the author’s arsenal. And, of course, it will help support the conversation with colleagues at the water cooler.
For whom the book
The book is very suitable for server-side web developers, development approaches are considered on the example of an online store. Well, if you have experience of participation in real projects, then in the course of the narrative analogies from life will arise - Mark managed to highlight real, uninvented problems and show how to solve them. If you are just starting your career, reading will not be so interesting, you have not yet felt the pain of development and support of any major project.
')
The book is for those who not only want to understand the "dependency injection" (for this there are articles shorter), but more for those who want to learn how to develop long-playing applications that can be developed.
main idea
In order to make a good durable project, the code must be structured, broken into modules that are as less related as possible - loosely coupled.
The benefits we get from using loose binding are not always obvious, but it manifests itself over time as the size and complexity of the developed code increases. (quote from the book)
The book is about how to achieve weak binding, including (but not only) using the OT. Linking code can be estimated, there are unambiguous quantitative indicators. For example, how many libraries are in your project, what references to each other do they have. It happened that your ASP.NET MVC project has a dll reference with Entity Framework entities? Or even does not refer, and contains Entity context? Reason to buy a book.
A typical web application consists of three levels.
Further reading will require some experience developing web projects. If you do not have it, then it will not be interesting.
Often, there are 3 levels of application:
- display level
- level of business logic
- level of data access
This Mark considers correct, in his opinion, it is possible to go further and divide the display level by two more and be 4.
Usually start with a data access level. And usually use the Entity Framework (EF) (nothing against EF is a great technology).
In articles and books about the Entity Framework, you can find descriptions of how great it is that the Code First model allows you to create domain POCO / DTO objects. How bad it is to use attributes in such POCO objects — binding to database tables should be done only using the Entity Framework Fluent Api. It is advised to have two projects:
- one with POCO objects (describe objects that lie in the database), let's call it Models
- the second one contains EF Context and Fluent mapping to the base, let it be DataAccessLayer
Thus, POCO objects seem to be “disconnected” from the “data access layer”. EF Context plays the role of repository.
In this scheme, it is easy to be deceived. Next, a BusinessLayer project is created in which:
- EF POCO objects are used as business entities (after all, they are “not connected in any way” with the database),
- EF Context is also used, linq queries are very convenient.
Thus, the BusinessLayer project contains references to Models and DataAccessLayer projects .
The display level queue is an ASP.NET MVC WebSite project that renders EF POCO objects. WebSite project has references on BusinessLayer and Models .
The scheme of dependencies of such a project in Figure 1. It can be seen that the entire application depends on the level of data access. The result is a strongly related code.
Figure 1. The dependency diagram of a highly related application (arrows in the direction of dependence)
Note: EF POCO objects are not actually business objects, they are one-on-one mapped on the database structure. They cannot be changed without changing the database schema; if the database is changed, you will need to rewrite all linq queries that are made in BusinessLayer .
To determine which dependencies between the layers are correct, Mark argues as follows: which part of the application does not make sense to change even in a hypothetical scenario?
- Theoretically, the display level may need to be replaced:
o say go to the new framework,
o or make simultaneously two levels of display: the site and the mobile application. - The level of data access can also be changed in theory:
o - new DBMS not supported by EF (weak argument, but we are considering hypothetical situations to identify the right dependencies),
o part of the data on objects can be moved to another database or a web service,
o finally file repositories for testing. - But if the level of business logic changes, we will get a new application. Fit to it the old base and the interface will not work.
Thus, all application layers should depend only on business logic. The business layer should not have dependencies at all - Fig. 2.
Fig 2. Correct dependency diagram
How will BusinessLayer get data without reference to DataAccessLayer and its repositories? In the book it is.
When examining the example, the author makes an interesting remark: not only the resulting dependencies are wrong, but also the order in which the layers are developed. It is necessary to start not from the database, and not from business objects, but from the display level. In the text you will find a step by step description of the development.
To be continued (?)
We talked about those to whom the book is addressed, briefly reviewed a typical web application. Mark Siman has cooked a lot more useful. The note turns out long, it makes sense to break it into blocks. Until new meetings.
Source: https://habr.com/ru/post/343830/
All Articles