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可以帮我们做很多工作。
所以说还是在运行时可以随意修改实体类的好，这样可以极大地避免修改代码的问题。（因为根本就没有啥代码）