Blood loss model, congestion Model

I. Blood Loss Model

In simple terms, the blood loss model is a pure data class that only has the getter/setter method of the attribute in the domain object.

Simply put, domain ojbect contains domain logic that does not depend on persistence, and those that rely on persistence are separated to the service layer.
Service (business logic, transaction encapsulation) --> Dao ---> domain object

Advantages of this model:
1. One-way dependency at each layer, clear structure, easy implementation and maintenance
2. Simple Design and stable underlying model

Disadvantages of this model:
1. The persistence domain logic of domain object is separated to the service layer, which is not oo
2. The service layer is too heavy

From the advantages and disadvantages, simple, stable, and easy to maintain are the biggest advantages of the blood loss model. The disadvantages are not object-oriented and are indeed not object-oriented. But for Small and Medium Projects, the business logic is not very complex, more demands lie in stable operation, maintenance, and scalability,

Obviously, this model, combined with ORM to implement codefirst, can achieve rapid development, saving manpower and costs, and is also favored by small and medium-sized projects. Why not. In addition, this model should be adjusted and modified according to the project's needs.

Cannot be difficult.

For example, in order to reduce the pressure on servers in various stages, reduce the coupling between various businesses, and improve the reusability of business modules, we have created a mall. A simple figure is drawn, so that the project needs to be easily implemented and the original module can be replaced.

Well, here we have to add one sentence. The design that meets the requirements is the most reasonable.

I. Congestion Model

The congestion model is similar to the anemia structure. The difference is that it puts most of the behavior or logic in its own related fields into the domain object, while the business layer or service only has a small amount of logic, simple logs, permissions, transactions, etc. In this way, the hierarchy becomes client> (business facade)> business logic> domain object> data access.
Advantages of this model:
1. More in line with OO principles
2. The service layer is thin. It only acts as a facade and does not deal with Dao.
Disadvantages of this model:
1. DAO and domain object form bidirectional dependencies. Complex bidirectional dependencies can cause many potential problems.
2. How to divide the service-layer logic and the domain-layer logic is very vague. In actual projects, due to horizontal differences between the design and developers, the entire structure may be disordered and unordered.
3. Considering the transaction encapsulation feature of the service layer, the service layer must provide corresponding transaction encapsulation methods for the logic of all domain objects, the result is that the service completely redefines all domain logic, which is very cumbersome, and the transactional encapsulation of the service is equivalent to converting the domain logic of OO to the service transactionscript in the process. The oo implemented by this congestion model on the domain layer has become a procedural model on the service layer. From the perspective of web-layer programmers, there is no difference with the anemia model.