Orm is not easy to use, maybe because you are using it in the wrong way

Some teams will abandon the object relationship ing framework (ORM) because they think it is not good enough or there are too many unknown factors, but it is usually caused by incorrect usage. In a recent speech, Jimmy Bogard emphasized the correct and incorrect methods when using Orm, including ing and query problems. Old Brand entertainment city

Jimmy is the creator of automapper and one of Microsoft's most valuable experts. He described ORM as a tool for getting data from the database, passing data to the application, and returning data to the database. This may seem a simple problem, but it is actually quite complicated.

A ing problem described by Jimmy is the ing code generated by the database, that is, the Code created by the tool from the existing database. This may seem attractive, but he often finds that there are too many relationships and unnecessary navigation, which may cause performance problems. Instead, Jimmy uses code-first to add the Mappings and relationships they need, even for existing databases.

In Jimmy's experience, when using Orm, The first thing developers complain about is that loading with excessive latency and loading with select n + 1, these features cause the ORM to delay loading all the data in a complex model, rather than reading data on demand. The problem is that it may lead to many database calls, for example, when one attribute is read at a time or a loop is performed on the set. On the contrary, Jimmy prefers to use "eager fetch" as much as possible to read all the required data in a request.

Jimmy believes that the repository mode is not a good idea. In the original book "Domain-driven design", repository was originally an interface and looks like a collection of data storage, but Jimmy believes that this mode has evolved into an appearance model above Orm, hides many features unique to Orm. In this mode, repository is just a stupid interface and is implemented only as an actual ORM proxy. To effectively use Orm, you must use these hidden features. This exposes the implementation details of the ORM to the application, making the repository a useless package on the Orm.

As an alternative to repository, Jimmer prefers to put all the code that processes a specific request into a class, so that each data request is modeled as a command or a query. In this way, changes, such as a new data access policy, are encapsulated into a specific class.

Jimmy's last bad idea was to ignore SQL. Orm is not a way to avoid understanding SQL. It is important for key business systems running on ORM to know what SQL is running and how its performance is.

Orm is not easy to use, maybe because you are using it in the wrong way