企业数据移动化
企业正努力通过RESTful接口实现企业数据的移动化，但开发移动应用和REST API是非常耗时的工作。
我们研究了两种技术，可以显著缩短上市时间。可执行的Schema(建立于模型驱动开发和约定优于配置)从现有Schema创建RESTful API和多表UI，只需要几分钟时间。声明式的行为为逻辑和安全带来类似电子表格的强大功能和简单性，它基于完全可编程的JavaScript模型。
我们将简要地回顾现有的关键技术，借助它们的先进性，吸取市场中的教训。然后我们将提供可执行的Schema和声明式行为的具体细节。
当前的方法
承诺加快交付速度是很有吸引力的，在过去十年间确实诞生了一些很棒的产品。首先，让我们简要分析当前的方法，从而得出一些经验教训。
模型驱动开发
模型驱动架构和模型驱动工程这样的方法，已经在构建部分系统元素方面有一些成功案例。虽然有承诺，但其真正的机会在于：
直接构建可执行的系统，而不是需要理解和集成的组件(如Beans、Transfer Object);
借助云/移动技术;
消除Model/Schema的冗余和同步的复杂性。
约定优于配置：Ruby, Grails……
生成可执行系统的概念已经被Ruby、Grails，Roo等流行的产品占据，它们使用约定优于配置，根据模型生成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，而且是马上就能用的。
