企业正努力通过RESTful接口实现企业数据的移动化，但开发移动应用和REST API是非常耗时的工作。

我们研究了两种技术，可以显著缩短上市时间。可执行的Schema（建立于模型驱动开发和约定优于配置）从现有Schema创建RESTful API和多表UI，只需要几分钟时间。声明式的行为为逻辑和安全带来类似电子表格的强大功能和简单性，它基于完全可编程的JavaScript模型。

我们将简要地回顾现有的关键技术，借助它们的先进性，吸取市场中的教训。然后我们将提供可执行的Schema和声明式行为的具体细节。

当前的方法

承诺加快交付速度是很有吸引力的，在过去十年间确实诞生了一些很棒的产品。首先，让我们简要分析当前的方法，从而得出一些经验教训。

模型驱动开发

模型驱动架构[1]和模型驱动工程[2]这样的方法，已经在构建部分系统元素方面有一些成功案例。虽然有承诺，但其真正的机会在于：

• 直接构建可执行的系统，而不是需要理解和集成的组件（如Beans、Transfer Object）；
• 借助云/移动技术；
• 消除Model/Schema的冗余和同步的复杂性。

约定优于配置：Ruby, Grails……

生成可执行系统的概念已经被Ruby、Grails，Roo等流行的产品占据，它们使用约定优于配置[3]，根据模型生成UI界面和代码。这是一个简单的Grails例子：

能够快速构建Web应用是一件好事，但如果要想获得显著的、更大的价值，就要实现：

应用能够更加完整。例如提供可编辑的（内嵌Lineitem修改）主/从表（显示订单的Lineitem）Grid，自动关联显示产品名称而不是数字；

• 提供多表业务逻辑支持（修改逻辑和安全业务逻辑非常冗长乏味）；
• 应用部署于云技术平台，REST和HTML 5/JavaScript；
• 避免生成代码的缺陷，例如当原始输入（数据模型）变化时，重复生成或丢失自定义逻辑。

移动后端

移动后端即服务（Mobile Backend as a Service，MBaaS）是一个新的分类，关注于云技术，例如REST/JSON。DreamFactory和SlashDB这样的产品为你的SQL数据创建了完整的RESTful API，并提供了便利的表格浏览用户界面。

但这肯定仅仅是个开始，如果你能实现以下功能，就不难想像其价值了：

• 扩展表浏览功能，实现完整的多表应用，提供主/从、导航等功能；
• 提供业务逻辑，确保数据修改时触发正确的计算和校验；
• 使用别名（Alias）/Projection提供自定义多表资源。

建议的方法

通过引入以下理念可以显著加强这些方法：

• 可执行的Schema，将Schema作为模型，你可以建立REST/云服务，预先为多表UI和API提供通用行为模式，这是个立即可执行的系统；
• 声明式、面向业务的行为能够提供声明式的API扩展、逻辑和安全行为支持。其真正的价值是在一个很高的抽象层面交付这些行为，这更像是面向业务的需求，而不是代码；
• 在标准语言中集成命令式语言支持。使用像JavaScript这样的标准语言，为模型提供程序事件支持。

所以，开发团队能够在接近业务的抽象层运行和交付，显著提高了速度。他们能将BDD故事翻译成可运行的软件，以确认理解和发掘下一组行为。这样就明显地减少了误解，因为相关干系人已经看到了正在运行的软件，读懂了“代码”。

可执行的Schema

要想有立竿见影的效果来满足业务需求，我们要运行现成的应用。也就是说，只要将我们的系统连接到Schema，就会有完全可执行的API和应用软件，正如下面所描述的。

默认的应用程序

建立一个具有丰富功能、支持移动的后台应用是有可能的。前提是虽然“前台”应用需要UI草图，但数据维护这一大类应用遵循一套常见的模式，它们可以通过Schema来创建。

下图演示了一些数据维护应用完整功能的常见模式：

• 搜索/过滤、分页列表/表单视图、可排序的列标题；
• 外键驱动的多表应用软件行为：
• * 主/从表（客户的多个订单）；
• * 下钻导航（第2张图，订单的项目，通过右下侧的放大镜或Zoom按钮）；
• * 自动表关联（Join）：显示产品名称，而不是数字编号；
• 数据编辑支持，包括可编辑的表格，查找（查找部分）和错误处理。

表关联功能非常有趣，它相当常见。在下面的例子中，Product外键是Product Number，而不是Name，这是很常见的模式。理想情况下，系统了解这种情况（数字外键，例如Product Number）并自动关联更适合的字段（Name）。我们不仅有可执行的Schema，而且是马上就能用的。

默认的REST API

RESTful API是云/移动应用的架构选择。该API不仅能提供移动应用接入，还可为其它系统提供Web Service访问。

数据库到REST的映射也非常直接，只需要：

• 为每个数据库表、视图和存储过程建立REST Endpoint；
• 提供Get/Put/Post/Delete支持（即常说的CRUD操作），并支持：
• * 过滤和排序；
• * 常见的模式，包括分页、分析数据库结构和相关的数据，以及乐观锁。

其结果是一个“扁平”的关系型API。这是个好的开始，但我们需要继续去扩展它。

声明式的行为

我们建议模型不要复制Schema，由于下面这些关键行为，因此有必要扩展它。

富REST API：多表资源、别名和Projection

我们的“扁平”API是个好的开始，但仍然需要富“面向文档”的API。该需求是为移动开发人员提供方便的API模型的同时，最小化多个查询的延时。

这样的对象有点像支持别名和Projection的关系型视图。但是，与视图不同，它们不是扁平的。它们支持嵌入的“子资源”对象，例如Order对象有LineItem和Shipment信息。

这样的“多表视图”可以通过点击，或者这样的语法进行定义：

Create Resource OrdersResource 
      from Orders (id as orderNumber, customer.name as customerName), 
      SubResource Items as LineItems via <fkName> 
         (name as product.name, qty as qtyOrdered…) 
      SubResource Shipment as Shipents via <FkName> 

         (…) 

逻辑：与电子表格相似的响应（Reactive）

业务逻辑是绝大多数系统的关键因素。它们通常是繁琐的代码、包含大量的变更检查和扩散逻辑，以及大量的SQL（包括缓存提升性能）等等。

通常认为，这样的逻辑是特定领域的（正确），并且必须以命令式和过程式语言进行开发（错误）。声明式的方法将能够显著提前和加速软件交付和维护。并且已经存在这样的解决方案。

目前越来越重视UI事件处理中的响应，例如模型到视图的同步。但最常用的是电子表格，当相关值发生变化时，单元格公式的响应，会进行重新计算，当然还能将它们串起来。虽然对非程序员来说很简单，但电子表格提供了足够的能力，解决了不同寻常的复杂性。

响应非常适合于数据库事务逻辑：

1. 给数据库表的列，或者“虚拟列”（是模型的一部分，用于事务处理，但并不物理保存）设置表达式；
2. RESTful Put/Post/Delete操作修改了关联的值时，将触发调整相应的值；
3. 同时进行校验（余额<信用）。

最有趣的事务是多表，按照我们的表达式，可以引用关联数据（customer.balance := sum(orders.amount_total where paid = false）。这让系统不仅能够检测变化，还要提供持久化（读取/写入相关数据、缓存和优化等等）。

需要注意的是对列的逻辑封装将导致继承复用。上面的例子中，我们声明的系统观察和响应orders.amount_total或paid标志的变化。

声明式的逻辑肯定是无序的。因此系统必须推导出执行顺序，例如通过依赖图。这对维护很有意义。自动排序意味着你增加/改变逻辑时，不需要担心执行顺序的具体细节。

由于省去了依赖管理、扩散和SQL处理，实现了意义非凡的简洁性和可读性。意义非凡指的是扩展了order的幅度，因此下面的逻辑，是虚拟的需求规范，是可以直接执行的：

lineitem.amount = row.product_price * row.qty_ordered 
lineitem.product_price = copy(row.product.price) 
orders.amount_total = sum(lineitem.amount) 
customer.balance = sum(orders.amount_total where paid = false) 

validate customer as row.balance <= row.credit_limit 

但是，没有银弹。并不是所有逻辑都能够声明，关键的条款需要正确地集成处理逻辑。这些在下面描述。

安全性

大多数系统的另一个关键需求是安全性。除了熟悉的端点接入，系统必须实现行和列的实例级别的安全性。例如，您可能希望某些人只能看到自己所在地区的订单。

很多系统在视图级别提供这样的功能，但这导致定义和维护大量的视图。一个更好的办法是将基于角色的安全性封装到表中，并确保它能够在跨多表资源时可以重用。

Role SalesRep authorized for Orders 

     Columns(orderDate, …) 

     Rows (region = $user.region) 

其中$user表示一种建议的机制，将用户与命名的值（例如region）关联，可以用于过滤表达式的参数。

程序扩展

可执行的Schema和声明式行为能够提供价值，但仅当它们与常见的程序扩展进行集成后才潜力无限。

服务端JavaScript

通过Schema可以直接为每个表创建JavaScript行对象类型，以及列和相关数据的存取方法。这很像Ruby Active Record，它们是持久化感知（Persistence-aware）和逻辑感知（Logic-aware）的。它们确保了在处理修改时，执行正确的响应逻辑。

此外，你能在服务端JavaScript中处理它们发布的事件。事件包括常见的模型（插入前、修改前）并对JavaScript提供完全的访问（发送消息、启动程序等）。JavaScript是一种优秀的语言，它几乎运行于所有系统，而且大多数开发者都相当熟悉。

UI创建

客户端的扩展性也很重要。默认的UI可能很强大和有效，但主要适合于后台应用程序。对于前台办公应用，有很多要求，因此应能够开发任何UI界面。

有两种可行的方法。第一，默认的UI可以正向工程（代码生成）到你偏爱的平台/IDE中，你将它作为起点。

或者，可以将内在的模型移出，将默认UI制作成组件，以参数化的iFrame方式嵌入到更大的应用程序中。这保持了模型间的关联，避免代码生成的“你拥有它”的影响。

自定义API

最后，创建声明式API丝毫没有消除构建自定义API的能力和需求。

总结

我们在这列出了现实的方法：

• 从现有Schema快速创建移动应用和默认的RESTful API；
• 扩展API，定义多表层级资源；
• 使用声明式“响应”表达式增加行为，管理修改逻辑和行访问，提供电子表格的简单性和强大功能；
• 与服务端JavaScript集成，提供复杂的行为。

作者注：Espresso Logic已经在实现这个愿景，提供了一些前面所描述的元素。如果你想试试，我们提供了免费的评估版本和零安装系统，你可以使用自己的数据库。我们始终期待与你交换意见，以提高我们的技术。