用node.js實現ORM的一種思路

 

　　ORM是O和R的映射。O表明面向對象，R表明關係型數據庫。兩者有類似之處同時也各有特點。就是由於這種便是又非的狀況，才須要作映射的。

　　理想狀況是，根據關係型數據庫（含業務需求）的特色來設計數據庫。同時根據面向對象（含業務需求）的特色來設計模型（實體類）。而後再去考慮如何作映射。可是理想很骨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查詢，還能夠按照其餘字段來查詢，好比分類字段。這樣效率就能夠獲得提高。

  先開個頭，還有後續。。。