需求背景
框架设计的时间点是2013年年底，当时我正在设计和开发一个可视化的开发平台。
这个平台的首要特点是——用户通过拖拽组件的方式，设计出表单，进而同步生成表单映射的业务对象的结构——譬如最简单的例子，用户对象映射的数据表是什么，有多少字段，每个字段名、字段类型又是什么，等等。
我们无法使用mybatis或hibernate这些业内比较常见的orm框架，因为他们本质上需要开发人员编写代码、sql，配置表和对象的关系，而平台的要求是这个过程是无代码化的。
也就是说，仅仅通过配置（本质上会创建出一个XML描述的业务对象），就需要可以通过API对业务对象进行CRUD或者更高级的操作。
设计思路
首先要解决的问题是——如果不用编码的方式，仅仅有一个配置信息（当然可以把配置文本映射成一个配置类），如何在内存中表示当前的业务对象？
代码生成器
当时有很多企业都采用这样的方式，通过eclipse插件配置业务对象，然后创建实体类、映射文件、DAO类、Service类等等。当时有很多企业都采用这样的方式，通过eclipse插件配置业务对象，然后创建实体类、映射文件、DAO类、Service类等等。
这类方法优点是：简单明了，缺点是：意义不大。。。对于项目前期生成代码还有点用，但是后期维护、修改还是需要成本，而且本质上修改的内容还需要重新编译、打包、部署。这类方法优点是：简单明了，缺点是：意义不大。。。对于项目前期生成代码还有点用，但是后期维护、修改还是需要成本，而且本质上修改的内容还需要重新编译、打包、部署。
动态编译
事实求实地说，那个时候觉得自己还不能很好的驾驭动态编译的技术，这是当时不考虑动态编译的主要原因。而且事后想来，最终的技术方案要比用动态编译生成class要简单的多。事实求实地说，那个时候觉得自己还不能很好的驾驭动态编译的技术，这是当时不考虑动态编译的主要原因。而且事后想来，最终的技术方案要比用动态编译生成class要简单的多。
弱类型对象
用一个Map或者数组，比如“用户”是一个Map，“公司”也是一个Map，只是它们的key的数量不同，这个很好理解，就不多赘述了。用一个Map或者数组，比如“用户”是一个Map，“公司”也是一个Map，只是它们的key的数量不同，这个很好理解，就不多赘述了。
优点：解决了动态对象的结构问题，缺点：对开发人员来说，在二次开发的时候，不如直接操作类那么友好（必须知道这个对象是什么类型，有哪些字段，字段对应的值又是什么类型等等）。优点：解决了动态对象的结构问题，缺点：对开发人员来说，在二次开发的时候，不如直接操作类那么友好（必须知道这个对象是什么类型，有哪些字段，字段对应的值又是什么类型等等）。
出于存储空间和读写性能考虑，原生数组比HashMap更加合适，另外为了外部访问对象更方法，可以让它实现Map接口。出于存储空间和读写性能考虑，原生数组比HashMap更加合适，另外为了外部访问对象更方法，可以让它实现Map接口。
对于传统的编码方式，定义一个类是常见的表示结构的方式，但鉴于上述需求，不能编码，也没有考虑动态编译，那么只有一条路——自定义一个接口，描述结构、甚至其他更多的内容，这里我们把这个接口称为“对象元数据”。
定义成接口的好处是，可以通过各种来源生成“对象元数据”，显然，通过配置对象，我们可以生成一个实现该接口的实现类，它创建的对象实例是一个基于数组的实例。
下面是一段伪代码：
Config userConfig = loadConfig("user");//加载用户的配置
IDataMeta userMeta = userConfig.createMeta();//根据配置创建元数据
Object user = userMeta.createObject();//创建对象实例
Map<String,Object> userAsMap = (Map<Strring,Object>)user;//我们确保user实例实现了Map接口
user.put("xxx",value)//设置属性
Object val = user.get("xxx")//获取属性
有了元数据，我们知道了不同业务对象的结构，那么根绝接口拼接DDL和DML语句也就有了可行性有了元数据，我们知道了不同业务对象的结构，那么根绝接口拼接DDL和DML语句也就有了可行性。
而且元数据是一个接口，除了配置之外，我们也可以通过定义一个POJO类+注解的方式，反射生成一个元数据实例。貌似和JPA+hibernate很像？是的，的确如此，但是pisces的ORM框架相比hibernate，用起来更简单、对于一些场景的处理方式也很不一样，当然功能不如hibernate全也是一定的。开发框架的目的是为了好用，如果比hibernate轻量、然后又不想写SQL（mybatis动态sql很强，但是大部分业务对象的CRUD也写SQL的话，未免也太啰嗦，嗯？我知道，还有个tkMybatis，目前我只能说它和pisces的ORM有点类似，但我相信无论hibernate还是tkMybatis，相比pisces都有其缺陷）。
时间回到现在，我正在对这套框架进行重写，毕竟上次开始动笔是5年前了，有必要对原先的框架进行梳理和优化。鉴于目前配置化编程不是首要需求，后续在讲述ORM的时候，我一律通过POJO类+注解的方式进行说明和演示。