Dependency injection in .Net Mark Siman 1 - Dependencies between application layers
Dependencies between application layers | Constructor implementation, lifetime | Cross-cutting aspects of the application, interception, decorator. The
principles of program development, called "Dependency Injection" (OT), are not a new topic, but no less interesting and useful. Even if you don’t know what the Dependency Injection Container is, you may already be using OT. Working 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 purport to be complete, is not a summary, and cannot replace Mark's work in any way. But, I hope, it motivates reading 379 pages (a total of 463 pages in the book) and shows interesting tricks from the author’s arsenal. And, of course, it will help to maintain a conversation with colleagues at the cooler with water.
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 in participating in real-life projects, then in the course of the narrative analogies will arise from life - Mark was able to identify real, far-fetched problems and show how to solve them. If you are just starting your career, reading will not be so interesting; you have not yet experienced the pain of developing and supporting any major project.
The book is for those who not only want to understand “Dependency Injection” (there are shorter articles for this), but more so for those who want to learn how to develop long-playing applications that can be developed.
To make a good, robust project, the code should be structured, broken up into as little as possible interconnected modules - loosely coupled.
The book is about how to achieve weak binding, including (but not only) using OT. Code coherence can be estimated; there are unambiguous quantitative indicators. For example, how many libraries in your project, what references they have to each other. It happened that your ASP.NET MVC project has a reference on dll with Entity Framework entities? Or is it not even referenced, but contains an Entity context? Reason to buy a book.
Further reading will require a little experience in developing web projects. If you do not have it, then it will not be interesting.
Often there are 3 levels of the application:
- the level of display
- the level of business logic
- the level of data access
This Mark believes is correct, in his opinion, you can go further and divide the display level by two more and there will be 4.
Usually they start with the level of data access. And they 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 POCO / DTO domain objects. How bad it is to use attributes in such POCO objects - binding to database tables should only be done using the Entity Framework Fluent Api. It is advised to have two projects:
- one with POCO objects (describe the objects that are in the base), let's call it Models
- the second contains EF Context and Fluent mapping to the base, let it be DataAccessLayer
Thus, POCO objects seem to be “disconnected” from the “access layer to data. " EF Context plays the role of a repository.
This scheme is easy to fool. Next, a BusinessLayer project is created in which:
- EF POCO objects are used as business entities (because they are "not connected" to the database),
- EF Context is also used, linq queries are very convenient.
Thus, the BusinessLayer project contains references to the Models and DataAccessLayer projects .
The display layer queue is an ASP.NET MVC WebSite project that renders EF POCO objects. The WebSite project has references for BusinessLayer and Models .
The dependency diagram of such a project is shown in Figure 1. It can be seen that the entire application depends on the Data Access Level. The result is a highly related code.
Fig. 1. Dependency diagram of a tightly coupled application (arrows toward the dependency)
Note: EF POCO objects are not really business objects, they are one-on-one mapped onto the database structure. They cannot be changed without changing the database schema; when changing the database, 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: what part of the application does not make sense to change even in a hypothetical scenario?
Therefore, all layers of the application should depend only on business logic. The business layer should not have dependencies at all - Figure 2.
Figure 2. The correct dependency scheme
How will the BusinessLayer receive data without reference to the DataAccessLayer and its repositories? This is in the book.
When considering the example, the author makes an interesting remark: not only the resulting dependencies are incorrect, but also the order of the development of the layers. You need 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. Marc Siman has prepared many more useful things. The note is long, it makes sense to break it into blocks. See you again.
principles of program development, called "Dependency Injection" (OT), are not a new topic, but no less interesting and useful. Even if you don’t know what the Dependency Injection Container is, you may already be using OT. Working 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 purport to be complete, is not a summary, and cannot replace Mark's work in any way. But, I hope, it motivates reading 379 pages (a total of 463 pages in the book) and shows interesting tricks from the author’s arsenal. And, of course, it will help to maintain a conversation with colleagues at the cooler with water.
Who is the book for?
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 in participating in real-life projects, then in the course of the narrative analogies will arise from life - Mark was able to identify real, far-fetched problems and show how to solve them. If you are just starting your career, reading will not be so interesting; you have not yet experienced the pain of developing and supporting any major project.
The book is for those who not only want to understand “Dependency Injection” (there are shorter articles for this), but more so for those who want to learn how to develop long-playing applications that can be developed.
main idea
To make a good, robust project, the code should be structured, broken up into as little as possible interconnected modules - loosely coupled.
The benefits that we get from using weak binding are not always obvious, but they do appear over time as the size and complexity of the developed code grows. (quote from the book)
The book is about how to achieve weak binding, including (but not only) using OT. Code coherence can be estimated; there are unambiguous quantitative indicators. For example, how many libraries in your project, what references they have to each other. It happened that your ASP.NET MVC project has a reference on dll with Entity Framework entities? Or is it not even referenced, but contains an Entity context? Reason to buy a book.
A typical web application consists of three levels
Further reading will require a little experience in developing web projects. If you do not have it, then it will not be interesting.
Often there are 3 levels of the application:
- the level of display
- the level of business logic
- the level of data access
This Mark believes is correct, in his opinion, you can go further and divide the display level by two more and there will be 4.
Usually they start with the level of data access. And they 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 POCO / DTO domain objects. How bad it is to use attributes in such POCO objects - binding to database tables should only be done using the Entity Framework Fluent Api. It is advised to have two projects:
- one with POCO objects (describe the objects that are in the base), let's call it Models
- the second contains EF Context and Fluent mapping to the base, let it be DataAccessLayer
Thus, POCO objects seem to be “disconnected” from the “access layer to data. " EF Context plays the role of a repository.
This scheme is easy to fool. Next, a BusinessLayer project is created in which:
- EF POCO objects are used as business entities (because they are "not connected" to the database),
- EF Context is also used, linq queries are very convenient.
Thus, the BusinessLayer project contains references to the Models and DataAccessLayer projects .
The display layer queue is an ASP.NET MVC WebSite project that renders EF POCO objects. The WebSite project has references for BusinessLayer and Models .
The dependency diagram of such a project is shown in Figure 1. It can be seen that the entire application depends on the Data Access Level. The result is a highly related code.
Fig. 1. Dependency diagram of a tightly coupled application (arrows toward the dependency)
Note: EF POCO objects are not really business objects, they are one-on-one mapped onto the database structure. They cannot be changed without changing the database schema; when changing the database, 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: what 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 let's say switch to a new framework,
o or do two display levels at the same time: the site and the mobile application. - The level of access to data can also be changed in theory:
o - a new DBMS not supported by EF (a weak argument, but we consider hypothetical situations to identify the correct dependencies),
o part of the data on objects can be transferred to another database or Web service,
o finally file repositories for testing. - But if the level of business logic changes, we will get a new application altogether. Adding to it the old base and the interface will not work.
Therefore, all layers of the application should depend only on business logic. The business layer should not have dependencies at all - Figure 2.
Figure 2. The correct dependency scheme
How will the BusinessLayer receive data without reference to the DataAccessLayer and its repositories? This is in the book.
When considering the example, the author makes an interesting remark: not only the resulting dependencies are incorrect, but also the order of the development of the layers. You need 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. Marc Siman has prepared many more useful things. The note is long, it makes sense to break it into blocks. See you again.