Never Use ORM to delay loading (lazy loading)

What is lazy loading? It is estimated that people on earth know that it means to load necessary data only when necessary, this avoids unnecessary system overhead caused by instant loading (this is what textbooks say ). In addition, an example is provided in the textbook. For example, when a user object is loaded, it will read multiple address objects associated with it at the same time. For applications that require address operations, the automatic loading mechanism of associated data is very effective. However, if we only want to obtain the sex attribute of the user, but do not care about the address information of the user, then loading the address feature is redundant, this results in a great waste of performance. In order to obtain the Gender attribute of users, we may also need to read several useless address data from the database at the same time, which leads to a large amount of unnecessary system overhead, so delayed loading is just like this, basically, most ORM systems have the feature of delayed loading.

So many benefits, why use it with caution?

First, delayed loading may easily lead to n + 1 select problems, but the performance is not guaranteed.

Second, delayed loading is generally implemented using bytecode enhancement in the Orm. Objects processed in this way will often cause Object serialization to fail, in large Web applications, an independent Cache architecture is generally used. 1. The application system introduces an independent cache system to cache application data objects. serialization of objects loaded with delayed loading will fail, the cache fails.

Third, the delayed loading in Orm makes the loading relationship of business objects unclear. If you want to change the ORM one day, you have to deal with the delayed loading relationship for different ORM systems, even if you don't pay back the Orm, it will be a headache for people who want to understand the loading relationship.

Fourth, the purpose of delayed loading is to make the application load only necessary data, reduce the amount of data transmitted, and increase the query speed. On the other hand, in order to reduce the pressure on the database to run unnecessary queries, avoid too many queries at a time and reduce system consumption. The first problem can be solved through the necessary cache, and the system consumption is generally tolerable. For the second problem, it is not a problem to use the required indexes for single-table queries at the business layer.

Fifth, on the other hand, Orm only needs to undertake o r m. Like transactions, caches, and other features, it should be undertaken by other more qualified guys, it does not need to carry out that load. Otherwise, it will be a daunting task for future underlying expansion.

It is recommended that you do not need to use the late loading feature in the ORM unless your system performance is really poor, and you need to delay loading to avoid this type of system consumption. Then you should consider using it again. Even if you want to use the delayed loading feature, it is recommended that you consider whether to add Independent Application cache and so on. Sometimes the root cause is system design problems.