For example, Object Persistence and ORM

The past few days have been quite lively. Recently, new books have been idle for the final stage, so I have come to join in. In fact, I have read the following two post posts and I have some thoughts, therefore, you are welcome to criticize and correct them.
One article is: Compare Hibernate and ado.net 2.0. Q? What other features of Hibernate are worth looking forward?
Article 1: domain model left (congestion), right (anemia)

Many Prawns have put forward their own ideas and have fully discussed the two topics. Here I just want to talk about my own views on the two topics involved.
One is object persistence and the other is Orm.

First, what is object persistence? Why is object persistence required?

In the first article, Xu Daxia raised ADO. net2.0's support for Object persistence. The so-called Object persistence, first of all, must be in the completely Ood, OOA, OOPProgramConcept, of course, there is no object persistence? When designing a program, we use cases to describe the problem field. In my personal opinion, in fact, use cases play the largest role in the process of establishing a domain model or in the process of establishing a problem domain, basically, it is difficult to understand what is mined after refining (when it comes to the database level, it cannot be Oo, such as sqlhelper, basically, the structure is a lot of static methods. In fact, there is no need to analyze them hard ). During the running process of the program, all classes and objects are stored in the memory, and the class status (that is, attributes) cannot exist permanently in the memory, because the memory is volatile, the state of all objects cannot be maintained after the program is restarted. For example, we created 10 user objects by default at the beginning of the program, however, a nickname attribute of a user is modified during the running process. If we restart the program at this time, the nickname attribute of this user cannot be saved after it is changed. At this time, we need to set the state of this object (the value of all attributes ----- is not necessarily all, because some attributes are based on other attributes. In the end, it depends on the design, it is the property that needs to be saved in the design) stored and can be loaded to the memory at any time as needed. This is the object persistence.

So how can we persist objects? There are too many methods. We can serialize and flat the class and store it in the file system, or store the object state in the database through the database component. We will design a table structure in the database to store the attributes of objects, and be able to quickly index a certain state of object storage in the database, and quickly restore to the memory.

Let's look back at it. when designing a program in. net, the way of thinking is actually the opposite. We first use database design tools to design the database structure and then start designing classes. At this time, many people will feel that OO is awkward, how can it be awkward? In fact, we have no premise when designing a database. what data is stored in the database? We need to store the object state in the database, so we must have the object to start the database design, and this design process is actually an OR Mapping design process, class design should be a prerequisite for database design. The class structure is a constraint for database structure design. We must design the database under this constraint and lower the optimization on this premise, in addition, only under this premise can we determine the fields that need redundancy as needed, and those that need table sharding should be used as the primary key. If this process is reversed, there will be two situations, or an analysis will be performed when designing the database to improve the design, then, when we design the category, we need to design it again, which leads to an increase in time requirements. At this time, many people may feel that the design is really over-designed. Either it is because you are not careful when designing the database (for sure, if you don't have any analysis, you will start to do it well). Then, after designing the class, you will find that there is something wrong with both ends, then change the two sides.

The final result is that OO is not good, pre-design is a waste of time, it is awkward to use, in fact, not Oo is wrong, but people are wrong, because when we find these problems, we completely reverse the process, we often make these mistakes, and often blame oo for their errors. In fact, there is no problem with OO, and our problems are indeed bigger.

Why is the design going from top to bottom? Here we need to specify a business system with a certain business logic, so the write-driven cool won't have to look at this section.
Because the so-called business system must conform to the business specifications and use the business as the design constraints to truly build a system. As for the Implementation Details, wow, everyone comes out to eat by writing programs, read and write databases, and write logs ........ to put it bluntly, the program is all these things in the final implementation. As for transactions, thread security, and cross-process synchronization, these zookeeper problems are considered during the design of the architecture, these are also the issues that architects need to consider. For example, enterpriselab does this. Of course, it does not matter if we implement something similar ourselves. In short, this is a big framework and reusable, we only need to design the business-related classes to put them in (ideally, most of the time we still need to do a lot of dirty stuff on our own ).

Can I use XP from top to bottom? Of course, we can quickly build a framework, write test cases, and implement them using pseudo logic in the class. At this time, the database is not designed yet, so we can start testing, if it is XP enough, we can fully design the business design at the beginning, and finally complete the database design and achieve persistence while ensuring stability. (It is best to make the database stable. Don't make a big change without moving it. It would be too bad if you leave for a week to visit and come back to see him) so in fact, from top to bottom requires more unit tests and more XP.

And now we have the ORM tool for the persistence function. We can use AOP to inject the persistence capability into the classes we designed so that the objects can be persisted.

Now let's talk about Orm. We don't have to say much about what an ORM is. It's everywhere.
In my understanding, Orm is a converter that converts the database structure into the object state.
What should we do with Orm? I think the role of ORM is the ability to implement persistence for objects. If we understand it like this, even if we only use ORM as a useful cuid tool, there will not be much problems, of course, if you are familiar with Orm, you can configure persistence functions. Therefore, no matter whether it is anemia or congestion, fatservice or thinservice, as long as we continue the correct method during the design, we will not feel awkward.

There is a gap between the ideal and the reality. First of all, this method does not apply to legacy systems. If too many legacy systems are reconstructed like this, it is not human-competent. Secondly, if there is no good architecture designer, there is no way to use it, and there is a problem with the understanding of the business. The analysis case class is not correct... the result is still painful. The quality of the programmer for re-encoding should be sufficient. Otherwise, the programmer may not understand it. It is still so awkward to use it (at least it seems like the encoding staff ).

Grandpa Deng said: no matter whether it's a white cat or a black cat, it's a good cat to catch. This is a masterpiece of the practical, but we cannot get stuck in this way, because the constraints of reality will not pursue the beauty of implementation, catch the consumption also depends on whether it is easy to believe or all the way to fight nose face catch the consumption, can improve our design why not perfect?

Note: This article is original to me and only represents my views and opinions at this time. Who knows what will happen in the future?