用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查询，还能够按照其余字段来查询，好比分类字段。这样效率就能够获得提高。

  先开个头，还有后续。。。