看到这个标题，你肯定会觉得这基本不可能，或者只能做一些简单的业务场景，不写代码。常规企业应用开发的基本流程为了实现我们的目的，我们先来看看常规企业应用开发的基本流程：第一步是在数据库中创建表和字段。第二步，在应用代码中创建表对应的业务对象，并实现对象之间关系相关的操作方法。第三步，UI层调用业务对象获取数据进行渲染，或者通过业务对象进行持久化操作。由于常规开发思维的惯性，我们想当然地认为要完成第二步和第三步，不写业务代码几乎不可能完成各种业务逻辑，只能写SQL和做配置。回归业务系统开发的本质让我们回到业务系统的本质，看看第二步和第三步做了什么。我们想象这样一种理想情况：如果最终用户是SQL专家，那么他应该完全可以通过一个SQL客户端来完成所有的业务逻辑。其实在40多年前，关系数据库的相关论文就已经论证了基于关系计算理论表达客观世界的完备性，所以上述理想情况才变得如此合理。那么我们不禁要问，在数据库上层开发的业务系统，解决的核心问题是什么？如上所述，关系计算理论和SQL（非常接近自然语言）已经可以处理各种复杂的业务逻辑，并具有自身的完备性。显然，我们在上层创建的应用显然不是为了解决数据库本身无法实现的业务逻辑，而是做额外的代码工作，而是为不懂SQL的人提供一个shell，让他们可以进行交互基于这个相对固定的UIshell，通过点击鼠标等一些简单的操作，可以方便、正确的完成一些后台的SQL操作。【图1单系统数据流】关系建模与面向对象世界观的冲突为了实现上述固定交互的UI外壳，我们不得不在应用层使用面向对象的方式来连接逻辑，并在这次我们必须让一些对象使用实体关系映射（ORM）。这也是关系建模体系与面向对象思想的内在冲突所在：前者是一个完整的建模体系，已经通过严密的数学和形式化推导得到论证，而后者是程序开发模型中的最佳实践。虽然有hibernate、mybatis等一些优秀的ORM框架可以解决这类问题，但是不要忘记我们业务逻辑的核心在于SQL的执行。为了达到这个目的，ORM的做法似乎还很遥远。那么，能否去掉第二步和第三步，只写SQL配置就可以完成系统开发呢？解决方案考察常规开发的第三步，我们会发现最终的输出其实是让用户操作UI来完成其背后对应数据库的IO操作，所以我们可以从两者中发现本质需求输入输出方面：1.在（OUTPUT）方面，由于关系数据库是基于表和字段的结构化表示，SELECT语句的结果可以直接呈现在页面上，无需中间代码处理。只要列表、表格、卡片等UI层的各个组件都支持相关数据的渲染和展示。另一方面（INPUT），用户进行的相关持久化操作更加程式化，即从页面获取各种数据汇总到后台执行UPDATE、INSERT、DELETE等一条或多条SQL（包括Transaction)操作，当然中间可能会有一些IFELSE处理细节。因此，为了达到本文的目的，我们制作了Enhancer云开发工作台，这是一个专门用于企业级信息系统开发的一站式工作台。用户可以基于这个工作台基本上只需要编写SQL进行配置，就可以快速完成所有的开发工作，获得一个可以私有部署的系统。本工作台作为一款开发功能完备的云端IDE，也主要做了以下两方面的工作，以实现只写SQL配置即可完成开发的目标：一方面，构建标准化的UI组件库（支持三种-partyextension），使组件的使用过程以可配置的形式呈现给开发者，并直接连接SQL进行数据组织或展示。另一方面，它提供了完整的可变数据体系和程序化的事件动作响应机制，让开发者可以按照这种程序化的模式快速完成各种复杂的业务数据持久化操作。【图2Enhancer所见即所得开发图】使用效果经过实战检验。这种开发模式比传统开发模式至少快10倍，迭代和维护成本大大降低。目前已有数万开发者使用该平台完成了涵盖各行业各种复杂信息管理应用场景的系统，详见案例。不同于其他只能开发简单业务系统的低代码开发工具，Enhancer基于Z-Model理论开发模型的完备性，支持所有业务场景的开发，不受任何技术限制。欢迎试用和指教。
