ORM itself originates from dachang politics. The programming language should be object-oriented. But database big factory wants to use SQL. The earliest ORM, that was TOPLink in 1995. There are written in Smalltalk. It was ported to JAVA. But then JAVA got its name, Hibernate. Hibernate even makes an HQL, perhaps its goal is to take over the world.
Object – oriented and relational database are two sets of technical specifications. Relational databases do not match object-oriented programs. This mismatch is called object-relational impedance mismatch. Of course, this impedance is not physically measurable, but the specification of the two technical systems.
For example, in the database system, there are a large number of unnecessary declaration and creation, such as tables, fields, etc., can be directly accessed. In object-oriented programming languages, any object needs to be created with the new operator. Database systems are time-dependent. In object-oriented programming languages, objects are completely dynamic and have no concept of time.
ORM is needed because of object relation impedance mismatches. However, after more than 20 years of ORM, almost none of them have been successful. The first reason is the architectural constraint that developers want to fully adapt to object-oriented languages. But SQL in relational databases is inherently incompatible with programming languages. Second, the big players didn’t do anything. JAVA did Hibernate, but it went in the wrong direction. It is intended to rebuild a system of relational databases using the programming language of surface objects, rather than just solving mismatched Bridges. Perhaps they were thinking about the future of object-oriented databases. However, object-oriented databases have not been implemented today. Of course, there is one thing that counts, and that is ElasticSearch. But it’s just an object-oriented index, and the underlying is still a relational database. And it’s not hard to see how many people are now using SQL to replace its query DSL. It has to be said that object orientation is still a lack of capabilities for relational databases. Microsoft’s database was still SQL, and there was nothing wrong with the big factory. At the same time, because it was exclusive, the development environment integrated query constructor, so there was no ORM in the early days. As a result, most of the people who switched from Microsoft to open source didn’t accept ORM. But then Microsoft came up with a LINQ. Third, there is no open source to make it a standard for ORM. This is, of course, a very difficult task, because there are many database vendors and many programming language vendors. Fourth, over the years, no one has been willing to move closer to each other. No programming language data type can carry data types from a database. In programming languages, there has never been an object that needs to be created and can be accessed by name. Men and women have equal rights. Yin and Yang calendar, you have your year, I have my year.
Now that relational databases are successful,SQL is unchallenged. Similarly, object-oriented programming languages have been successful. Now, at least, the average person needs only three objects to write a program. The three basic objects are: Model Model, View View, Controller Controller. All other objects can be used as libraries wrapped in classes, nothing more. So, some people say, object orientation, that’s all. That’s because not many people really know 23 design patterns.
However, ORM has brought great disaster to the development of software industry, Internet industry and computer technology. The first disaster is: increased programmer burden, an old programmer, if the programming language, then, he used several sets of ORM libraries, certainly not single digits. There may be dozens or hundreds of versions. Also, a large number of ORM libraries are often sought, for what purpose? The first is the complexity of ORM. Second, open source ORMs continue to be introduced. ORM is ostensibly designed to reduce programmer learning costs, but in essence, there is no ORM that frees programmers from the details of the database because of abstraction loopholes. This was Joel in 2002, all self-evident abstractions are flawed. Abstract leakage refers to any abstraction that tries to reduce or hide complexity. It does not completely shield details. Complex details that try to be hidden are always likely to leak out. Abstract vulnerability law states: any time an abstraction tool can improve efficiency, although it saves our working time, but it can not save our learning time. Code generation tools such as ORM and Hibernate do the same. It abstracts something, but all abstraction mechanisms are flawed. The only way to deal with vulnerabilities is to know how abstraction works, what it abstracts. So, in the process of understanding the principle of abstraction, the Time gods will recoup the time you saved.
The second major disaster of ORM is that it wastes huge amounts of energy. Because, earlier OM was all technical route, Hibernate is definitely a model, and there is a Doctrine in PHP that is almost completely copied. This does not mean that the technical route is not good, the technical route can be put in the laboratory, also can be put in the research institute. But the products of the early technology route, not only make the application a guinea pig, but also add a lot of unnecessary code, resulting in a lot of performance overhead, which is a waste of energy. It wasn’t until Roby On Rails came along and provided ActiveRecord’s ORM that the world saw that ORM could do the same thing. ActiveRecord is killing almost every programming language involved. JAVA has it, Python has it, PHP has it… . However, the best user experience so far is Eloquent in PHP. It’s pretty much the best in the world in terms of user experience (the programming experience for programmers). It also has a Python version: Orator.
The third disaster of ORM is that it adds a lot of development costs to software, which many users pay a high price for, and there are a lot of startups that would be successful without a complex or crappy ORM. But many have disappeared. One of the most important reasons is the wrong ORM.
The fourth disaster of ORM is the technology selection barrier. In general software development, the first is to choose the development framework, but today a development framework without ORM, it is not a framework. ORM can ruin you if you choose the wrong framework, and you can’t change it. The most typical is ThinkPhp, its arguments can be (a, B, C) or ([‘a’=>[‘b’,’c’]]), this kind of non-documentation, opaque convention, you can only spend time with it source code, but IF the source code is seven or eight layers IF nested, how do you feel? Or allowFields is a model that raises an error if you are in sync with it. However, there are not many entrepreneurial teams who know what is a good ORM, and in the end, the project is delayed and delayed, all in common sense.
ORM’s fifth disaster is that it kills the creativity of a lot of programmers, a lot of programmers all over the world who are writing ORMs, who are writing frameworks, who are simply creating a lot of junk code out of nowhere. These programmers might have done better if they had focused their efforts elsewhere. But that’s not the case.
If ORM is so bad, why are there so many people using it? First, they really want to achieve some purpose with ORM, such as program specification, code readable, development efficiency, program security. But now ORM, the program specification is done ok. While the code is readable, the DBA cannot coordinate the code with the programmer, and the programmer is often required to type out the SQL statements. In terms of development efficiency, many seemingly accelerated development speed, resulting in a large number of bugs wasted time is not a small number of code writing time is shorter, but debugging is multiplied by several times. As for security, since ActiveRecord, data access has become more and more convenient, that is, more and more exposed. In this case, the ORM’s total vulnerability is the easiest place to play. Second, ORM is only used for psychological comfort, thinking that bare SQL is not safe, SQL injection is relatively easy, security is not controllable. Secondly, because I heard that ORM has the advantages of program specification, code readable and development efficiency, so I follow the crowd. Essentially, it’s all about 100 percent psychological comfort.
So, is ORM a knot that will never be untied? It depends on a number of things. The first is whether both the object and the relationship can compromise, and if one of them compromises, then there will be new innovations. Second, if there is a real ORM standards body that can drive the standardization of ORM, then ORM will develop in a positive direction. Third, among the social forces, the strength of university research groups is quite strong. If these forces join in, perhaps the standardization of ORM will be further improved.
So what makes a good ORM in the real world? A good ORM should have the following good structure. First of all, DBAL, the database access layer, good data access layer support is not difficult, but some ORMs, from time to time, the database down, or let the database deadlock. These are the minimum requirements, and as for clustering, master-slave support is a must today. Second, the query constructor. A good ORM must make it easy for the programmer to construct queries. An approximate equivalent mapping of SQL is required. Why is that? Think about it, equivalence mapping, it’s the cheapest thing for programmers to learn. Select (field.id, field.name.as(student_name)). From (student). Where (condition.age.lte(30); This kind of statement, programmer easy to understand, DBA also understand. Of course, currently the program does not support name-based objects, nor does it support functions. Third, the model layer, the good model layer should provide the best user experience for the programmer’s most common needs. ActiveRecord for Ruby On Rails has been successful in providing the best add, delete, change and query operations for a single table. From a product perspective, products have to be easy to use, easy to use, and useful. Ease of use is number one. If there is no alternative, it doesn’t matter if it’s easy to use. As long as it works. Fourth, the data processing layer, which is used for post-processing of data, generally uses collection objects with extended capabilities. The query constructor and model layer is the architecture of the existing ORM. This architecture is arguably the most chaotic of all. The reason is that the first function of the model is to provide database object mappings that the model can use in mapping tables and views. At the same time, map the data in the table. But this is done by mapping objects to attributes, not by name. So, whenever you want to use something, you use the new operator. In plain English, a model is a composite of configuration and query API objects for data mapping. The goal is to start with the model, write less code, and be able to use the query constructor with ease, and finally get results from the collection. The first thing the model does is tell the programmer what tables are in the database, what fields are in the table, but most of the models don’t tell the programmer what functions are there, what program logic keywords or expressions are there. However, this approach to the model seems to be the best solution in object-relational mapping at present. Imagine if the mapping used a full-name object tree. Today’s ides can prompt array members dynamically, so this seems like a good idea. But for now, there seems to be no such solution. In addition, the model provides the user with a single table operation. Multiple tables use the main query results to check the way, the original JOIN statement to separate, hasOne, hasMany and other ActiveRecord methods although useful, but for performance, is a disaster. On the other hand, MVC is by no means a perfect architecture, and with ActiveRecord, it’s not uncommon to have a thousand or two thousand lines of code in your model. For this reason, Reposotory+Service was used to further improve MVC. A Model can only be a table, and Reposotory + Service can break this limitation.
A good ORM is essentially a development experience. For a software and Internet enterprise, fast development is king, so it is necessary for ORM to sacrifice some efficiency in exchange for fast development. The territory is not valuable. However, some rudimentary orMs can also spell disaster for a project. For example, thinkPHP Model, primary key is not mandatory, but run a large number of show table query table structure SQL, is still called efficient, efficient where? In terms of development experience, it is the ORM that is most difficult to implement. The first is dynamic prompt and autocomplete. Because databases are name access objects, they are completely different from OOP languages. The IDE can only dynamically prompt properties and methods in existing classes. SQL is a special DSL, and everything is based on communicating with the database to get information about tables, fields, and so on. By doing so, the database becomes a client. So, most of the time, it’s all about balancing and providing the easiest way to develop quickly. However, it is always frustrating for programmers because there is always a difference with SQL clients. But so far, none can fully implement the 100 percent built ORM in SQL programs. Early ORMs had this goal, but because of the limitations of OOP programs themselves, the development experience was greatly reduced. Since ActiveRecord, people have found that simplicity is king. This is why PHP and Golang have been adopted by a large number of users. And that’s why MVC is so popular. Simple, MVC, you just have to know these three classes basically. At this point, unless OOP has name-access object support, object-relational impedance mismatches will always exist. The ORM disaster will continue. A word of advice to developers who have overreached frameworks or open source, without a deep understanding of both systems and their predecessors, is not to develop an ORM. I would like to advise the technical leader of the startup team to be careful when selecting the technology. At least, choose STAR on Github which has many open source sources, including those conforming to open source specifications, such as detailed documentation, unit testing, continuous integration through various CI programs such as TRAVIS-CI. Testing code coverage is worth looking at. Not 29% all the time, like some frameworks. I really don’t understand, such coverage, there are a large number of users, see propaganda, listen to nonsense. And what does it say, free, should know gratitude. It’s free. You have to volunteer to be a guinea pig?
Finally, I would like to recommend some good ORM. For.NET, it’s LINQ, the official product that’s pretty awesome, I don’t need to tell you. JAVA, is JOOQ, all used, heart understand. JOOQ author’s concept, SQL is SQL, not program, so he broke the previous ORM convention, completely belongs to a kind of innovation, and this innovation to programmers bring development experience is quite good. After JOOQ came out, some people in China said ORM was a complete failure. Yes, ORM doesn’t offer the same experience as JOOQ. But we can say that JOOQ is the real ORM. Python, Orator, this is a project from porting PHP Eloguent. Eloquent for PHP, of course, addresses one of the most common pain points in development, but Eloquent for complex SQL is not so Eloquent. For a good experience, Dsql is a good choice. Old-line Propel is good, but development is now mostly Laravel or Swoft, which also uses Eloguent. Of course, if you insist on TP, then you are a natural masochist, so I won’t say more.