首頁 > web前端 > js教程 > 主體

使用Node.js實作ORM的思路

小云云
發布: 2018-01-03 13:52:57
原創
1342 人瀏覽過

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中文網其他相關文章!

相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板