使用Node.js實(shí)現(xiàn)ORM的一種思路詳解(圖文)

ORM是O和R的映射。O代表面向?qū)ο?，R代表關(guān)系型數(shù)據(jù)庫。二者有相似之處同時也各有特色。就是因?yàn)檫@種即是又非的情況，才需要做映射的。

網(wǎng)站的建設(shè)成都創(chuàng)新互聯(lián)公司專注網(wǎng)站定制,經(jīng)驗(yàn)豐富,不做模板,主營網(wǎng)站定制開發(fā).小程序定制開發(fā),H5頁面制作!給你煥然一新的設(shè)計(jì)體驗(yàn)!已為砂巖浮雕等企業(yè)提供專業(yè)服務(wù)。

理想情況是，根據(jù)關(guān)系型數(shù)據(jù)庫（含業(yè)務(wù)需求）的特點(diǎn)來設(shè)計(jì)數(shù)據(jù)庫。同時根據(jù)面向?qū)ο螅ê瑯I(yè)務(wù)需求）的特點(diǎn)來設(shè)計(jì)模型（實(shí)體類）。然后再去考慮如何做映射。但是理想很骨jian感dan，現(xiàn)實(shí)太豐fu滿za。

沒見哪個ORM是這么做的，也沒見哪位高手會這么做設(shè)計(jì)。那么實(shí)際情況是什么樣子的呢？以.net的Entity Framework為例。

DB frist，就是先設(shè)計(jì)好數(shù)據(jù)庫，然后根據(jù)庫里的表、主外鍵等自動創(chuàng)建實(shí)體類。然后可以通過LinQToSQL來操作。這樣創(chuàng)建出來的實(shí)體類顯然缺乏面對對象的特色。

Code frist，就是先設(shè)計(jì)實(shí)體類，然后根據(jù)實(shí)體類和特性來自動創(chuàng)建表和主外鍵、約束等。而為了嚴(yán)謹(jǐn)，定義實(shí)體類的時候需要說明一下主外鍵等具有關(guān)系型特色的東東。

如下圖

現(xiàn)在想用node來做一套引擎。剛剛接觸node，估計(jì)會有現(xiàn)成的orm吧，不知道他們是怎么做的，先不管他們了，先把自己的思路弄清楚再說，恩恩。

為啥要選擇node呢？以為他原生支持json。Json在前端那是主場，js原生支持json，各種操作都非常流暢舒服。但是json到了后端（C#）就麻煩了，C#原生不支持json，只能作為字符串，或者實(shí)體類序列化的形態(tài)。這就需要轉(zhuǎn)來轉(zhuǎn)去的，很是麻煩。

而采用node那么后端也可以用js來編碼，也就是說會原生支持json。這就舒服多了。想想，前端創(chuàng)建json（實(shí)體類），然后整個提交給后端，后端接到j(luò)son直接進(jìn)行處理（安全驗(yàn)證、業(yè)務(wù)處理），然后直接持久化。是不是很爽！

采用node還有一個好處，那就是他可以在運(yùn)行時定義實(shí)體類的屬性，比如增加屬性。這個在C#里是無法實(shí)現(xiàn)的。

為啥一定要運(yùn)行時可以修改實(shí)體類？因?yàn)檫@樣做可以避免實(shí)體類數(shù)量爆炸。

打開你的項(xiàng)目，數(shù)一數(shù)定義了多少的實(shí)體類？是不是項(xiàng)目越大實(shí)體類就越多？當(dāng)需要發(fā)生變化，需要給實(shí)體類增加一個屬性的時候，是不是需要各種改代碼？雖然VS可以幫我們做很多工作。

所以說還是在運(yùn)行時可以隨意修改實(shí)體類的好，這樣可以極大地避免修改代碼的問題。（因?yàn)楦揪蜎]有啥代碼）

這一篇主要是說思路，所以先簡單設(shè)計(jì)一個json來表示一下。

設(shè)計(jì)這個json的目的是，引擎可以根據(jù)json的情況來拼接成SQL，然后交給數(shù)據(jù)庫處理。

{
 "operationMode":"add",// add\update\delete\select
 "tableCount":1, //支持多表的級聯(lián)添加、修改
 "fieldInfo":[{//主表的字段，參與操作的字段，不參與的不用寫。第一個字段是主鍵（不支持多主鍵）
 "tableName": "t1", //表名。
 "primaryKey":"id",//主鍵字段名。我不想把主鍵字段名限制為必須是“ID”
 "_sqlCache": "" ,//緩存的sql語句，每次都拼接sql也挺煩的，弄個緩存存放拼接好的sql。
 "fieldList":{ //涉及到的字段，并不需要把表里的字段都放進(jìn)來，根據(jù)業(yè)務(wù)需求設(shè)計(jì)
   //客戶端提交的json與之對應(yīng)
 "field1Name":"field1Value",
 "field2Name":"field2Value"
 }
 },
 { //從表的字段，可以不設(shè)置
 "primaryKey": "id", //主鍵字段名。我不想把主鍵字段名限制為必須是“ID”
 "foreignKey": "foreignKeyid", //主鍵字段名。我不想把主鍵字段名限制為必須是“ID”
 "_sqlCache": "", //緩存的sql語句，每次都拼接sql也挺煩的，弄個緩存存放拼接好的sql。
 "fieldList": { //涉及到的字段（不含外鍵字段），并不需要把表里的字段都放進(jìn)來，根據(jù)業(yè)務(wù)需求設(shè)計(jì)
   //客戶端提交的json與之對應(yīng)
 "field1Name": "field1Value",
 "field2Name": "field2Value"
 }
 } // 從表的字段，參與操作的字段，不參與的不用寫。第一個字段是主鍵，第二個字段是外鍵
 ],
 "findCol":[{
 "colName":"col1",
 "key1":"abc",
 "key2":"abc", //范圍查詢時使用，比如從幾號到幾號
 "findKind":" {colName} like {key}" //查詢方式：like、not Like、in、=、between等
 }]
}

一般的ORM是以實(shí)體類為核心，要求實(shí)體類的完整，就說一個實(shí)體類要和一個完整的表做映射。比如要下架一個商品，一般的做法是先把這個商品從數(shù)據(jù)庫里讀取出來實(shí)例化之后，修改標(biāo)記屬性（字段），然后再把整個實(shí)體類持久化（保存到數(shù)據(jù)庫）。

但是SQL怎么寫呢？一個update就可以了，不用讀取數(shù)據(jù)的，這樣效率就有點(diǎn)損耗。

那么如果要把一個分類的商品都下架呢？要把這個分類里的商品都折騰出來，然后批量改屬性值，在批量持久化。

如果寫SQL語句呢？還是那一句SQL，只不過是把查詢條件換一下，還是不需要折騰數(shù)據(jù)。這種情況下效率的差別就很大了。

而我的這個思路呢，并不是以面向?qū)ο鬄楹诵牡?，而是以關(guān)系型數(shù)據(jù)庫為核心。

就是說不會把實(shí)體類和表做整體的映射，而是會把屬性和字段做映射。就是說把一個表里的部分字段拿出來，做成一個實(shí)體類，然后進(jìn)行操作。比如下架商品的例子

表：商品表

字段：isxiajia = 1

條件：id=1（單商品下架）  cate=2 （按照分類下架）

然后生成update語句就可以了。

這是一個獨(dú)立的“實(shí)體類”，這個類里面并不需要商品的其他屬性，因?yàn)橹皇窍录懿僮鳌Ａ硗獠樵儣l件也完全放開，不是僅僅依據(jù)ID查詢，還可以按照其他字段來查詢，比如分類字段。這樣效率就可以得到提升。

總結(jié)

 以上所述是小編給大家介紹的使用Node.js實(shí)現(xiàn)ORM的一種思路詳解，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對創(chuàng)新互聯(lián)網(wǎng)站的支持！