Une idée pour implémenter ORM en utilisant Node.js

ORM est une cartographie de O et R. O signifie orienté objet et R signifie base de données relationnelle. Les deux ont des similitudes mais ont aussi leurs propres caractéristiques. C’est à cause de cette situation du bien et du mal qu’une cartographie est nécessaire. Cet article présente principalement une explication détaillée (images et texte) d'une idée d'utilisation de Node.js pour implémenter ORM. Les amis qui en ont besoin peuvent s'y référer. J'espère que cela pourra aider tout le monde.

La situation idéale est de concevoir la base de données en fonction des caractéristiques de la base de données relationnelle (y compris les besoins métier). Dans le même temps, le modèle (classe d'entité) est conçu en fonction des caractéristiques de l'orientation objet (y compris les exigences métier). Réfléchissez ensuite à la manière de réaliser la cartographie. Mais l’idéal est très maigre et la réalité est trop riche et trop pleine.

Je n'ai jamais vu aucun ORM faire cela, et je n'ai jamais vu aucun expert le concevoir de cette façon. Alors, à quoi ressemble la situation réelle ? Prenons l'exemple d'Entity Framework de .net.

DB doit d'abord concevoir la base de données, puis créer automatiquement des classes d'entités basées sur les tables, les clés primaires et étrangères, etc. Ensuite, il peut être exploité via LinQToSQL. La classe d'entité ainsi créée manque évidemment de fonctionnalités orientées objet.

Le code consiste d'abord à concevoir la classe d'entité, puis à créer automatiquement des tables, des clés primaires et étrangères, des contraintes, etc. en fonction de la classe d'entité et des caractéristiques. Par souci de rigueur, lors de la définition des classes d'entités, vous devez expliquer les choses avec des caractéristiques relationnelles telles que les clés primaires et étrangères.

Comme indiqué ci-dessous

Maintenant, je veux utiliser Node pour créer un moteur. Je viens d'entrer en contact avec node. Je suppose qu'il existe des ORM prêts à l'emploi, je ne sais pas comment ils font, je vais les ignorer pour l'instant et clarifier mes propres idées.

Pourquoi choisir node ? Je pensais qu'il supportait nativement json. Json est le champ d'accueil au niveau du front-end. js prend en charge nativement json, et toutes les opérations sont très fluides et confortables. Mais json est en difficulté lorsqu'il atteint le backend (C# ne prend pas en charge nativement json et ne peut être utilisé que comme sérialisation de chaîne ou de classe d'entité). Cela nécessite des déplacements, ce qui est très gênant.

Avec node, le backend peut également être encodé en js, ce qui signifie que json sera supporté nativement. C'est beaucoup plus confortable. Pensez-y, le front-end crée du json (classe d'entité), puis soumet le tout au back-end. Le back-end reçoit le json pour un traitement direct (vérification de sécurité, traitement métier), puis le conserve directement. N'est-ce pas génial !

Un autre avantage de l'utilisation de node est qu'il peut définir les attributs des classes d'entités au moment de l'exécution, comme l'ajout d'attributs. Ce n'est pas possible en C#.

Pourquoi la classe d'entité doit-elle être modifiée au moment de l'exécution ? Car cela peut éviter l’explosion du nombre de classes d’entités.

Ouvrez votre projet et comptez combien de classes d'entités sont définies ? Est-ce que plus le projet est grand, plus il y a de classes d’entités ? Lorsque les besoins changent et qu’un attribut doit être ajouté à la classe d’entité, dois-je modifier le code de différentes manières ? Bien que VS puisse nous aider à faire beaucoup de travail.

Par conséquent, il est préférable de modifier la classe d'entité à volonté pendant l'exécution, ce qui peut grandement éviter le problème de la modification du code. (Parce qu'il n'y a pas de code du tout)

Cet article concerne principalement les idées, je vais donc simplement concevoir un json pour l'exprimer.

Le but de la conception de ce json est que le moteur puisse le fusionner en SQL en fonction de la situation json, puis le transmettre à la base de données pour traitement.

{
 "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等
 }]
}

Général ORM prend les classes d'entités comme noyau et nécessite l'intégrité des classes d'entités, c'est-à-dire qu'une classe d'entités doit être mappée à une table complète. Par exemple, si vous souhaitez supprimer un produit des étagères, l'approche générale consiste à d'abord lire le produit dans la base de données et à l'instancier, puis à modifier les attributs de la balise (champs), puis à conserver la classe d'entité entière (enregistrez-la dans la base de données).

Mais comment écrire du SQL ? Une simple mise à jour suffit, il n'est pas nécessaire de lire les données, l'efficacité sera donc quelque peu perdue.

Et si vous souhaitez supprimer tous les produits d'une catégorie ? Il est nécessaire de jeter tous les produits de cette catégorie, puis de modifier les valeurs d'attribut​​par lots et de les conserver par lots.

Et si vous écriviez une instruction SQL ? C'est toujours le même SQL, mais les conditions de requête sont modifiées et il n'est toujours pas nécessaire de modifier les données. Dans ce cas, la différence d’efficacité est énorme.

Et mon idée n'est pas basée sur une base de données orientée objet, mais sur une base de données relationnelle.

Cela signifie que les classes et les tables d'entités ne seront pas mappées dans leur ensemble, mais que les attributs et les champs seront mappés. C'est-à-dire, prendre certains champs d'une table, en faire une classe d'entité, puis effectuer des opérations. Par exemple, un exemple de retrait de produits des rayons

table : Table des produits

champs : isxiajia = 1

Conditions : id=1 (un seul produit retiré des rayons) cate=2 (selon classification Supprimé)

puis générez une instruction de mise à jour.

Il s'agit d'une "classe d'entité" indépendante. Cette classe ne nécessite pas d'autres attributs du produit car il s'agit simplement d'une opération de suppression. De plus, les conditions de requête sont également complètement libéralisées. Au lieu de simplement interroger sur la base de l'ID, vous pouvez également interroger sur d'autres champs, tels que les champs de classification. De cette façon, l’efficacité peut être améliorée.

Recommandations associées :

La méthode de définition du modèle d'URL et les règles de mappage du servlet et du filtre

Introduction à l'identité orientée objet PHP cartographie

Introduction au mappage ORM à l'aide d'annotations

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!