An idea to implement ORM using Node.js

ORM is a mapping of O and R. O stands for object-oriented and R stands for relational database. The two have similarities but also have their own characteristics. It is because of this right and wrong situation that mapping is needed. This article mainly introduces a detailed explanation (pictures and text) of an idea of ​​using Node.js to implement ORM. Friends in need can refer to it. I hope it can help everyone.

The ideal situation is to design the database according to the characteristics of the relational database (including business requirements). At the same time, the model (entity class) is designed according to the characteristics of object-oriented (including business requirements). Then think about how to do the mapping. But the ideal is very skinny, and the reality is too rich and full.

I haven’t seen any ORM do this, and I haven’t seen any experts design it this way. So what does the actual situation look like? Take .net's Entity Framework as an example.

　DB frist is to design the database first, and then automatically create entity classes based on the tables, primary and foreign keys, etc. in the library. Then it can be operated through LinQToSQL. The entity class created in this way obviously lacks object-oriented features.

Code frist is to design the entity class first, and then automatically create tables, primary and foreign keys, constraints, etc. based on the entity class and characteristics. For the sake of rigor, when defining entity classes, you need to explain things with relational characteristics such as primary and foreign keys.

As shown below

Now I want to use node to make an engine. I have just come into contact with node. I guess there are ready-made ORMs. I don’t know how they do it. I will ignore them for now and clarify my own ideas first. Yes.

Why should you choose node? I thought it natively supports json. Json is the home field at the front end. js natively supports json, and all operations are very smooth and comfortable. But json is in trouble when it reaches the backend (C#). C# does not natively support json and can only be used as a string or entity class serialization. This requires moving around, which is very troublesome.

Using node, the backend can also be encoded in js, which means that json will be natively supported. This is much more comfortable. Think about it, the front end creates json (entity class), and then submits the entire thing to the back end. The back end receives the json and processes it directly (security verification, business processing), and then directly persists it. Isn’t it great!

Another advantage of using node is that it can define attributes of entity classes at runtime, such as adding attributes. This is not possible in C#.

Why must the entity class be modified at runtime? Because this can avoid the explosion in the number of entity classes.

Open your project and count how many entity classes are defined? Does the larger the project, the more entity classes there are? When the needs change and an attribute needs to be added to the entity class, do I need to change the code in various ways? Although VS can help us do a lot of work.

Therefore, it is better to modify the entity class at will during runtime, which can greatly avoid the problem of modifying the code. (Because there is no code at all)

This article is mainly about ideas, so I will simply design a json to express it.

The purpose of designing this json is that the engine can splice it into SQL according to the json situation, and then hand it over to the database for processing.

{
 "operationMode":"add",// add\update\delete\select
 "tableCount":1, //支持多表的级联添加、修改
 "fieldInfo":[{//主表的字段，参与操作的字段，不参与的不用写。第一个字段是主键（不支持多主键）
 "tableName": "t1", //表名。
 "primaryKey":"id",//主键字段名。我不想把主键字段名限制为必须是“ID”
 "_sqlCache": "" ,//缓存的sql语句，每次都拼接sql也挺烦的，弄个缓存存放拼接好的sql。
 "fieldList":{ //涉及到的字段，并不需要把表里的字段都放进来，根据业务需求设计
   //客户端提交的json与之对应
 "field1Name":"field1Value",
 "field2Name":"field2Value"
 }
 },
 { //从表的字段，可以不设置
 "primaryKey": "id", //主键字段名。我不想把主键字段名限制为必须是“ID”
 "foreignKey": "foreignKeyid", //主键字段名。我不想把主键字段名限制为必须是“ID”
 "_sqlCache": "", //缓存的sql语句，每次都拼接sql也挺烦的，弄个缓存存放拼接好的sql。
 "fieldList": { //涉及到的字段（不含外键字段），并不需要把表里的字段都放进来，根据业务需求设计
   //客户端提交的json与之对应
 "field1Name": "field1Value",
 "field2Name": "field2Value"
 }
 } // 从表的字段，参与操作的字段，不参与的不用写。第一个字段是主键，第二个字段是外键
 ],
 "findCol":[{
 "colName":"col1",
 "key1":"abc",
 "key2":"abc", //范围查询时使用，比如从几号到几号
 "findKind":" {colName} like {key}" //查询方式：like、not Like、in、=、between等
 }]
}

General ORM takes entity classes as the core and requires the integrity of entity classes. That is to say, an entity class must be mapped to a complete table. For example, if you want to remove a product from the shelves, the general approach is to first read the product from the database and instantiate it, then modify the tag attributes (fields), and then persist the entire entity class (save it to the database).

But how to write SQL? Just an update is enough, there is no need to read the data, so the efficiency will be somewhat lost.

So what if you want to remove all products in a category? You need to get rid of all the products in this category, then change the attribute values ​​in batches, and persist them in batches.

What if you write a SQL statement? It’s still the same SQL, but the query conditions are changed, and there is still no need to mess with the data. In this case, the difference in efficiency is huge.

And my idea is not based on object-oriented, but on relational database.

That means that entity classes and tables will not be mapped as a whole, but attributes and fields will be mapped. That is to say, take some fields from a table, make them into an entity class, and then perform operations. For example, the example of removing products from the shelves

table: product table

field: isxiajia = 1

condition: id=1 (single product removed from the shelves) cate=2 (according to classification Removed)

Then generate the update statement.

This is an independent "entity class". This class does not require other attributes of the product because it is just a removal operation. In addition, the query conditions are also completely liberalized. Instead of just querying based on ID, you can also query based on other fields, such as classification fields. In this way, efficiency can be improved.

Related recommendations:

The url-pattern setting method and mapping rules of servlet and filter

Introduction to PHP object-oriented identity mapping

Introduction to ORM mapping using annotations

The above is the detailed content of An idea to implement ORM using Node.js. For more information, please follow other related articles on the PHP Chinese website!