随着互联网的发展，软件规模越来越大，工场手工业式编码方式已经不适应软件发展的需求。
本文先从使用环境分析原因，然后再提出解决方案。
1. ORM使用的大环境发生了变化
随着互联网的发展，软件行业在最近的五年，有了新的发展特点。数据往大的发展，有了大数据；服务往小的发展，有了微服务。互联网系统的主要特点：高并发访问，不允许宕机，对运行环境越来越苛刻。NOSQL数据库、微服务及分布式的出现主要就是为了解决这些问题。软件需求越来越复杂了，虽然出现的新技术，也能基本解决苛刻的需求了，但是软件生产率并没有提高。
软件需求越来越复杂，软件规模越来越大，从而产生编码复杂度太高与软件需求增多不适应的矛盾；市场总是在扩大，需求总是在增加，工场手工业式的编码方式已经不适应软件发展的需求。
1.1 十年前使用软件的大环境
十年前，PC机（个人电脑）的内存还是256k，512k为主流，再往前，内存就更小了。为了节省空间，编写的程序都是很精练的。是否还记得有这样一道算法题：不用额外的变量，交换两个变量的值。连一个临时变量的空间都节省了。现在的PC机内存已是4G，8G为主流了，服务器的内存就更大了。为了提高执行效率，一般都会采用空间换时间的方式。从编码层面到缓存组件再到缓存数据库，都可以找到空间换时间的例子。时间复杂度与空间复杂度是计算机学科核心课程《数据结构》的重要概念，这两个概念侧重在提高运行效率与节省内存空间上。
1.2 现在使用软件的大环境
但是现在使用软件的大环境与十年前的大不相同了，需求越来越复杂，变化越来越快，导致软件规模越来越大，交付时间反而要求越来越短。犹如十年前，很多是建10层楼，现在建100层。虽然框架结构的技术跟上了，但每个房间所要砌砖的速度并没有增长10倍。那只能是加人，或者延长工人砌砖时间。在软件行业，由此产生了许多为HW、ZX等做外包的软件工作者。许多软件工作者，经常加班，还是有很多软件没能按期交付，因为架构技术进步了，编码技术却没有相应提升。换个角度，降低编码复杂度，软件生产率自然就提上去了。软件行业除了艰苦奋斗，也需要创新，需要提高软件生产率，提高软件生产力。
1.3 软件编码的发展及软件生产力
市场总是在扩大，需求总是在增加。工场手工业不再能满足需要的时候，蒸汽和机器就引起了工业生产革命。软件是否也需要这样的变革？使用软件的大环境变了，不能再用原先的工场手工业方式进行编码了，应该采用低编码复杂度的方法，减少些无谓的人工编码。要是按照原来的编码技术（或方法），软件规模增长10倍，那编码量也就增长10倍，编码复杂度就是O(n)。在这个信息爆炸式增长的时代，这种效率根本无法满足软件的发展需要。若编码复杂度从O(n)降到O(1)的话，编码量就不会再随着软件规模的级数增长，就可以减少许多编码的活，从而解放生产力。Bee框架将ORM层的编码复杂度从O(n)降到O(1)，是将哲学思维应用到软件学科的一个例子。Bee仅仅只是降低编码复杂度的其中一个例子而矣，其它许多软件都可以降低编码复杂度，从而提高软件开发的效率，提高软件生产力。
2. 流行的ORM工具存在的编码效率问题
为了讨论编码效率问题，采用编码复杂度来衡量。编码复杂度用于描述编码量与所解决问题的规模的关系。如，在ORM编程中，当用面向对象方式操作一个DB表时，要写一份dao文件；当操作两个表时，要写两份dao；当操作n个表时，要写n份dao；则此时编码的复杂度会随着问题规模增长为n，编码复杂度也增长为n。关于问题n的编码复杂度(Coding Complexity)用C(n)表示。则上面描述问题的编码复杂度为:C(n)=O(n)。
在Java语言领域，ORM工具经过十多年的发展，编码复杂度仍为O(n)，软件生产率并没有提高。流行的ORM工具存在的编码效率问题主要有：[3]
对于每个实体，需要写一个dao接口文件。编码复杂度C(n)=O(n)，即会随实体的增长，编码量呈线性增长。当n较大时，会增加许多工作量。
实体Javabean与DB表的map映射文件太多；或者，实体Javabean文件注解太多,难以记忆。
任意组合查询条件需要提前编写接口方法；查询操作若用非id字段作为查询条件，需要在接口文件新定义方法。如一个实体有10个字段，2个字段组合一个查询方法，则有个查询方法；若算上3个字段，4个字段的组合，则更多。
需要写很多的判断字段是否为空（null)，是否是空字符串的语句；工作重复，乏味。
3. Bee框架的改进
在Bee框架的设计中，探讨一种可以提高软件生产率的方法。Bee框架的主要设计目标有：
编码复杂度为C(n)=O(1), ORM操作DB的工作量由n变1，生产率由1变n。
所有的Suid操作都是用同样的Bee接口,不用再定义任何新的dao接口,更不用另外实现dao接口。
动态/任意组合查询条件,不需要提前准备dao接口,有新的查询需求也不用添加和修改接口。
约定优于配置:Javabean没有注解,也不用xml,只是纯的Javabean即可。
自动过滤null和空字符串(作为默认实现)。可以很方便地只插入非空的部分字段和只更新部分字段。
直接返回Json格式查询结果，减少多次转换数据格式开销。
设计的API有规则,利于自动化生成代码。
既要编写少的代码，也要用自动化工具尽量多生成常规代码，让开发者可以节省更多的时间关注业务逻辑的开发。
软件系统数据变迁的一般流程如下：
对软件系统进行高度抽象，它的目的无非是对输入的数据进行处理，然后输出处理好的数据（可以是保存到DB，返回给请求端等），如图1所示。前端页面对数据名称等的变更以及底层物理数据库对表字段名称的变更等，ORM层不应该受到影响才是比较理想的。ORM层位于中间部位，不应该受到始末两端的影响。ORM层不属于输入与输出部分，不应该与具体的表或Javabean耦合，而应该将表或Javabean看作是无区别的一种抽象类型，处理经过抽象后的抽象类型。Bee框架就是将任何数据库表对应的实体类型看作是无区别的一种抽象类型，处理经过抽象后的抽象类型，将编码复杂度从O(n)变为O(1)，工作量由n变为1。图1所示软件系统模型，并不依赖于具体语言，也就是说，Bee只是本文所探讨思想的一种实现而矣，整个软件学科都可以应用这种思想。
4. 旧的ORM框架可以满足这种AI的功能吗
AI智能编程，产品原型出来，软件原型也出来了。所见的效果，所得就是可运行的代码。
但旧的ORM框架，API的方法命名没有规律，提供的接口方法太多，无法胜任快速自动生成代码要求。而Bee框架的Suid接口，就只有四个常用的方法，后来为复杂的查询添加了一个方法。这几个常用的方法，就可以完成80%的功能。
5. 存在的误区--天天要编写的代码，没有被普遍列为研究对象
21世纪是个创新的世纪，中国也在提倡创新驱动。软件行业受互联网的影响，信息爆炸式增长，那么多的代码需要编写，用旧的手工式编程根本无法满足需要，一天25小时，加班加点都没法满足，何况一天就24小时，还要睡觉！计算机专业、软件专业的人，都学过《数据结构》这门核心课程，都知道时间复杂度与空间复杂度。以前的内存就那么几k，为了省内存，交换两个变量还不用定义临时变量。
但现在内存动辄几G，谁还会在乎一个变量所要占用的空间，再说那样写代码可读性也不高。倒是天天要编写的代码，没有被列为研究对象。编码复杂度用来衡量编码效率，研究编码量是否受软件规模增长的影响。
腾讯云提供
