ORM是O和R的映射。 O代表物件導向，R代表關聯式資料庫。二者有相似之處同時也各有特色。就是因為這種即是又非的情況，才需要做映射的。本文主要介紹了用Node.js實現ORM的一種思路詳解(圖文),需要的朋友可以參考下，希望能幫助大家。
理想情況是，根據關係型資料庫（含業務需求）的特性來設計資料庫。同時根據物件導向（含業務需求）的特性來設計模型（實體類別）。然後再去考慮如何做映射。但理想很骨jian感dan，現實太豐fu滿za。
沒見哪個ORM是這麼做的，也沒見哪位高手會這麼做設計。那麼實際情況是什麼樣子的呢？以.net的Entity Framework為例。
DB frist，就是先設計好資料庫，然後根據庫裡的表、主外鍵等自動建立實體類別。然後可以透過LinQToSQL來操作。這樣創造出來的實體類別顯然缺乏面對物件的特色。
Code frist，就是先設計實體類，然後根據實體類別和特性來自動建立表格和主外鍵、限制等。而為了嚴謹，定義實體類別的時候需要說明一下主外鍵等具有關係型特色的東東。
如下圖
現在想用node來做一組引擎。剛接觸node，估計會有現成的orm吧，不知道他們是怎麼做的，先不管他們了，先把自己的思路弄清楚再說，恩恩。
為啥要選擇node呢？以為他原生支援json。 Json在前端那是主場，js原生支援json，各種操作都非常流暢舒服。但是json到了後端（C#）就麻煩了，C#原生不支援json，只能作為字串，或是實體類別序列化的形態。這就需要轉來轉去的，很麻煩。
而採用node那麼後端也可以用js來編碼，也就是說會原生支援json。這就舒服多了。想想，前端創建json（實體類別），然後整個提交給後端，後端接到json直接進行處理（安全驗證、業務處理），然後直接持久化。是不是很爽！
採用node還有一個好處，那就是他可以在執行時間定義實體類別的屬性，例如增加屬性。這個在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怎麼寫呢？一個update就可以了，不用讀取資料的，這樣效率就有點損耗。
那麼如果要把一個分類的商品都下架呢？要把這個分類裡的商品都折騰出來，然後批量改屬性值，在批量持久化。
如果寫SQL語句呢？還是那一句SQL，只不過是把查詢條件換一下，還是不需要折騰資料。這種情況下效率的差異就很大了。
而我的這個想法呢，不是以物件導向為核心的，而是以關聯式資料庫為核心。
就是說不會把實體類別和表格做整體的映射，而是會把屬性和欄位做映射。就是說把一個表格裡的部分欄位拿出來，做成一個實體類，然後進行操作。例如下架商品的範例
表：商品表
欄位：isxiajia = 1
條件：id=1（單一商品下架） cate=2 （依照分類下架）
然後產生update語句就可以了。
這是一個獨立的“實體類別”，這個類別裡面並不需要商品的其他屬性，因為只是下架操作。另外查詢條件也完全放開，不是僅依據ID查詢，還可以依照其他欄位來查詢，例如分類欄位。這樣效率就可以提升。
相關推薦：
servlet與filter的url-pattern設定方式及映射規則
PHP物件導向的識別映射介紹
使用註解進行ORM映射介紹
以上是使用Node.js實作ORM的思路的詳細內容。更多資訊請關注PHP中文網其他相關文章！
