Why is it not OO to put persistence in domain object.

The argument will always exist in the crowd, and its disappearance will mean the destruction of human civilization...

A long time ago, there was a debate on ORM in garden. during that period, my concepts of OO and ORM were gradually established in the words filled with smoke. recently I have discussed whether to put persistence in book. I think it is quite similar to the previous ORM controversy.

Speaking of ORM, everyone should be in favor of the development of information systems, which can be divided into two main methods: database-centric and oo-centric.

1. database-centric. obviously, the database structure will be designed at the initial stage of development, including tables, fields, and links based on stored procedures and other objects. then the upper-layer business logic and performance layer are implemented based on the database. in fact, domain object is no longer necessary for systems developed in this way. you can use Aspx. in the CS file, a datareader reads the database content and then displays it. in fact, the so-called strong data set is actually a ing of the physical database in the memory. business entities and other such things are unnecessary.

2. design the system with OO as the center. first, the first step is to design business processes and entity classes, and then design the database structure as needed, and Use ORM to bridge between the entity class and the database. for oo-centered design, during the design time, business processes, logic, and entity classes are the key points of the center. In the initial stage or even the main stage of design, databases, persistence, and other things will not be given priority. from this point of view, persistence is because the memory is too small and the computer will lose power before it has to need something. in the future, the data will be persisted, which is not a very definite problem.

I also found a post about Martin Fowler's anemia model and rich domain object. I personally think it is good. the first one is similar to a database-centric approach. The entities in the anemia model do not bring any extra value except for providing strong types; martin Fowler advocates rich domain object. we can see that the item instance has some business logic, and the final persistence is completed by itemmanager. the original Article also pointed out that the item should not depend on itemdao.

Finally, this article also mentions the third method. This method is similar to the self-persistence of objects in book. Save proposed by Comrade Alexander.

I didn't mean to deny this method. But how can this method be regarded as OO? If you design the system in OO mode, how can you consider the persistence problem when designing the entity class? Has it deviated from the concept of OO?

What needs to be clarified is that I personally think the entity class should implement certain business logic, similar to the example of man's borrow and lend method proposed by Comrade Alexander. what I highly disagree with is that the persistence method saved in the book proposed by Comrade Alexander is a very OO design.

I am very confused. If book. Save implements persistence, it means that the book object is dependent on the persistence layer. How can many people say this is decoupling! Very confused!