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