Node.jsを使ってORMを実装するアイデア-jsチュートリアル-php.cn

Node.jsを使ってORMを実装するアイデア

小云云

リリース： 2018-01-03 13:52:57

オリジナル

1336 人が閲覧しました

ORM は O と R のマッピングです。 O はオブジェクト指向を表し、R はリレーショナルデータベースを表します。この 2 つは似ている点もありますが、それぞれ独自の特徴もあります。この善悪の状況があるからこそ、マッピングが必要となるのです。この記事では主にNode.jsを使ってORMを実装するアイデアを詳しく解説（写真と文章）して紹介していますので、困っている方の参考になれば幸いです。

リレーショナルデータベースの特性（ビジネスニーズも含む）に合わせてデータベースを設計するのが理想的です。同時に、オブジェクト指向の特性（ビジネス要件も含む）に合わせてモデル（エンティティクラス）を設計します。次に、マッピングを行う方法を考えます。しかし、理想は非常に痩せていて、現実はあまりにも豊かで豊かです。

これを行う ORM を見たことがありませんし、このように設計した専門家も見たことがありません。では、実際の状況はどうなっているのでしょうか？ .net の Entity Framework を例に挙げます。

DBファーストとは、まずデータベースを設計し、ライブラリ内のテーブルや主キー、外部キーなどをもとにエンティティクラスを自動作成することです。その後、LinQToSQL を通じて操作できるようになります。この方法で作成されたエンティティクラスには、明らかにオブジェクト指向の機能が欠けています。

コードファーストは、最初にエンティティクラスを設計し、次にエンティティクラスと特性に基づいてテーブル、主キーと外部キー、制約などを自動的に作成します。厳密にするために、エンティティクラスを定義するときは、主キーや外部キーなどのリレーショナル特性を使用して説明する必要があります。

以下に示すように

今度はノードを使用してエンジンを作成したいと思います。ノードに触ったばかりですが、既製の ORM がどのように機能するのかはわかりません。とりあえず無視して、自分の考えを説明します。

なぜノードを選択する必要があるのですか？ jsonをネイティブでサポートしていると思いました。 Json はフロントエンドのホームフィールドであり、js はネイティブでサポートされており、すべての操作が非常にスムーズで快適です。ただし、json はバックエンド (C#) に到達すると問題が発生します。C# は json をネイティブにサポートしておらず、文字列またはエンティティクラスのシリアル化としてのみ使用できます。そのためには移動する必要があり、非常に面倒です。

nodeを使えばバックエンドもjsでエンコードできるので、jsonがネイティブにサポートされることになります。これははるかに快適です。考えてみると、フロントエンドは json (エンティティクラス) を作成し、それをすべてバックエンドに送信し、バックエンドは直接処理 (セキュリティ検証、業務処理) のために json を受け取り、それを直接永続化します。すごいじゃないですか！

ノードを使用するもう 1 つの利点は、属性の追加など、実行時にエンティティクラスの属性を定義できることです。これは C# では不可能です。

なぜ実行時にエンティティクラスを変更しなければならないのでしょうか？これにより、エンティティクラスの数の爆発を回避できるためです。

プロジェクトを開いて、エンティティクラスがいくつ定義されているか数えてください。プロジェクトが大きくなるほど、エンティティクラスの数も増えますか?ニーズが変化し、エンティティクラスに属性を追加する必要がある場合、さまざまな方法でコードを変更する必要がありますか?ただし、VS は多くの作業に役立ちます。

したがって、実行時にエンティティクラスを自由に変更する方が良いです。これにより、コードの変更の問題を大幅に回避できます。 (コードが全くないので)

この記事はアイデア中心なので、それを表現するためのjsonを単純に設計していきます。

この json を設計する目的は、エンジンが json の状況に応じて SQL に結合し、データベースに渡して処理できるようにすることです。

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

ログイン後にコピー

一般的な ORM はエンティティクラスをコアとして使用し、エンティティクラスの整合性を必要とします。つまり、エンティティクラスは完全なテーブルにマップされる必要があります。たとえば、商品を棚から削除する場合、一般的なアプローチは、まずデータベースから商品を読み取ってインスタンス化し、次にタグ属性 (フィールド) を変更してから、エンティティクラス全体を永続化します (エンティティクラス全体を保存します)。データベース）。

でもSQLってどうやって書くの？アップデートするだけで十分で、データを読み込む必要がないので、若干効率は落ちます。

それでは、カテゴリ内のすべての商品を削除したい場合はどうすればよいでしょうか？このカテゴリのすべての製品を削除し、属性値をバッチで変更し、それらをバッチで永続化する必要があります。

SQL文を書いたらどうなるでしょうか？同じ SQL ですが、クエリ条件が変更されており、データをいじる必要はありません。この場合、効率の差は非常に大きくなります。

そして、私のアイデアはオブジェクト指向ではなく、リレーショナルデータベースに基づいています。

つまり、エンティティクラスとテーブルは全体としてマッピングされませんが、属性とフィールドはマッピングされます。つまり、テーブルからいくつかのフィールドを取得し、それらをエンティティクラスにして、操作を実行します。例えば商品を棚から削除する例

テーブル:商品テーブル

フィールド:isxiajia = 1

条件:id=1 (単一の商品を棚から削除) cate=2 (カテゴリーごとに棚から削除)

次に、更新ステートメントを生成します。

これは独立した「エンティティクラス」です。このクラスは単なる削除操作であるため、プロダクトの他の属性を必要としません。さらに、クエリ条件も完全に自由化され、ID に基づいてクエリを実行するだけでなく、分類フィールドなどの他のフィールドに基づいてクエリを実行することもできます。このようにして、効率を向上させることができる。