Is ORM an evolution or regressing?

I. No ORM

Process-oriented programming was the mainstream, and object-oriented programming has become the mainstream. Process-oriented and relational databases are naturally compatible, or relational databases are originally prepared for process-oriented programming.

 

Fig 1.1

Figure 1.1 shows the relationship between process-oriented programming and data. In fact, the relationship between object-oriented programming and data is also the same in the early days, and can also be used in object-oriented programming.

 

Fig 1.2

In Figure 1.2, it is an Orm. EquivalentProgramSplit one more piece, and the granularity is refined.

Ii. Orm ideas

Fig 2.1

The idea of ORM is to use a rule to convert a database model to an object. It is similar to the red glass with sunlight.

Iii. What does ORM bring?

SlaveCodeFrom the processing point of view, programming is a process of dealing with the relationship between variable code and immutable code. What does ORM bring about? The biggest feature of ORM is to solidify the data object into the code and advance the running tasks to the compilation period.

4. Is ORM evolving or regressing?

Does ORM evolve or regress?

First, program development proves that maintaining only one version is optimal. However, the ORM actually copies the database structure. Now we need to maintain the relational structure of the data structure that has already been an object at the same time. In my opinion, it is a step backwards in programming. Although most ORM frameworks now provide tools for generating object objects, that is to say, the process of generating this copy is automated.

The original intention of ORM is to rely on configuration, but it is not actually completely dependent on configuration. Of course, this is related to C # and Java is a static language. It may be better if it is a dynamic language. Of course I have not tried it, just guess.

For a long time, the thought of a three-tier architecture is that changing one layer does not affect another layer. Orm uses the model across three layers to achieve this goal. Of course, this kind of overlay is not needed if reflection is used. Across three layers, the three layers are dependent on the model, which I think is also a bad thing. Because the model follows database changes, it cannot be guaranteed that the model changes will not affect other layers. The most basic idea of object-oriented programming is to solidify things and propose things of change. However, to keep the model unchanged, the database must not be changed. I don't think this is ideal. In actual development, the database structure changes frequently. Maybe you only add when talking about changes. Maybe, of course, I only think this is feasible theoretically.

5. What else can we do without an Orm?

This is probably the next generation of data access. I think object-oriented programming has not been able to solve all problems yet. Now there are many aspects that have highlighted its shortcomings. Therefore, there have been new theories to supplement it. As for object-oriented databases, we still need to solve at least two problems, not to mention how long objects last. It is very difficult to synchronize objects with databases. For example, db4o, if the object adds a new familiarity, it cannot be reflected in the database. What will happen in the future.