O/R Mapping

O/r m is a very common concept, but it is also a concept that many people misunderstand. O/r m is generated from the Java Community as far as I know, and it has completely changed to the. Net community. First, let's see why O/r m is not R/o m? In fact, the reason why many people do not understand the meaning of O/r m is that they did not fully consider the above issue.
Is O-dominated or R-dominated? From the perspective of object-oriented analysis, or from the perspective of relational analysis.

From the perspective of object-oriented, this means that you can use the characteristics of encapsulation, integration, and Polymorphism to describe and understand your application domain, because the object is highly abstract and understandable, through this model, you can construct a model that uses objects to describe the domain, which is also the origin of the domain model. A good model must take into account the reasonable responsibilities of objects, the rational relationship between objects, and the high cohesion, low coupling is a technical standard used to measure them.
We can see that a good domain model can give you a clear understanding of the real application fields, and a good domain object must also have a high cohesion and low coupling characteristics, rather than a data packet.
When we use object-oriented technology to establish our domain model, a question arises, and how can objects be persisted? The lifecycle of an object includes multiple stages, including the first creation, persistence, extraction from a file (usually a database), and garbage collection. Obviously, we want to pay more attention to domain models than to manage the lifecycle of these objects. At this time, the O/r m demand came into being, the transparent implementation of Object Persistence and anti-persistence is more pursued by us, now let's take a look at some practices that use O/r m to implement Save Load for a domain object, which is contrary to our ideas. What is the relationship between these methods and the domain? The O/r m framework separates the object persistence function from the domain object and submits it to the framework for responsibility. Some people actually do the opposite. This phenomenon is particularly common in the. Net community. Why? This is because the problem has different ideas. In the. Net community, O/r m is often used as R/o m.

From the perspective of relational models, after a problem is encountered, an entity-link model is established, various constraints are considered, and the business logic is described through a series of storage procedures on the Server side. This method has been widely used. However, what are the advantages and disadvantages of the two phases? Like most people (Martin Fowler and so on), I prefer the OO method and use objects to describe the world. Compared with the relationship and a bunch of SQL languages, the former is obviously more beautiful for me, without inheritance polymorphism, the program will be full of repeated code, which is not conducive to expansion and readability, let alone. As Martin Fowler said, if it wasn't because. Net provided a convenient interface binding method, who would use this pure data packet object? Their advantages lie in the simple logic application in those fields, which is also a common application field of. Net.

Therefore, if you do not use the object method (not to say that you only use the object-oriented language) to analyze and solve the problem, please stay away from O/r m. This is good for everyone. You won't think it's strange, nor will it be depressed by your use.

Here I will also share my thoughts on DLinq. First of all, I have to admit that it is Cool and I have introduced it before, but I don't like it very much. At least it has a risk of misuse. Query the data you need, and then process the data. Microsoft still sticks to its usual style, and in Linq, it can be said that it is extremely convenient to query data with Linq. If every object is obtained in this way, the Association between objects will become messy. The relationships between objects that you carefully consider when designing objects will be easily disrupted (the associations of domain objects are one of the key components used to describe domain models ), in addition, what you query is purely data entities, and they are not acted upon. You will manage them by xxxManager one by one. Oh, my God, they lose the object-oriented advantage. Therefore, DLinq is definitely not a set of O/r m tools, but it is a good choice to use it to implement a set of O/r m tools.

When the face-to-face impedance to objects and relational databases is out of balance, the Java Community is more concerned with the automatic and transparent implementation of O ing into R, MS is more concerned with converting R to O (data packet type O only) (this may be related to MS, which is also related to the database vendor ). Which one do you choose?

Personal opinions are for reference only.

A brother of BTW asked me about the performance of O/r m? Haha, there are always many people who are concerned about performance issues. Let me first ask you
What do you think of OO performance? How about generic performance? What is the performance of AOP? What is the performance of SOA? Another disappointing answer is that their operation efficiency is lower than the solution that does not use them. However, they can greatly enhance our development efficiency. This is an era in which efficiency is pursued.
(I don't mean to despise performance)

6.8 updated after reading comments

Many people may have different opinions in this article, which is quite normal. For example, this article is just a mess. However, if you are using Hibernate, consider what I mentioned as much as possible, because my point of view is basically the same as that of Gavin King (author of Hibernate. For more information about the table, see the original Gavin King.

You shoshould use Hibernate if you have a nontrivial application (definition of nontrivial varies, but I usually think of Hibernate being less applicable to applications with only ten tables or so) that use an object-oriented domain model. not every application needs a domain model, so not every application needs ORM. but if your application does a lot of business logic-rather than just displaying tabular data on a webpage-then a domain model is usually a good thing.

Hibernate really starts to shine in applications with very complex data models, with hundreds of tables and complex interrelationships. for this kind of application, Hibernate will take away a huge amount of coding effort (perhaps up to 25%, for some applications) and will result in an application that performs better than the alternative handcrafted JDBC. this is possible because some kinds of performance optimizations are very difficult to handcode: caching, outer-join fetching, transactional write-behind, etc.

In addition, Pisces pointed out in his comment that "the size of data does not have much to do with the technical framework used, but business complexity is quite relevant", which I personally agree.

If you want to understand O/r m in depth, we recommend the following three books:
Patterns of Enterprise Application appseture
Hibernate in Action
Domain-Driven Design

Related Articles