——最简单的方式:零代码,在页面上配置好参数,自动生成 SQL 并且直接转化成 HTTP API。
进入演示,账号:admin,密码:123123
Java 企业级开发中,要写 Model、DAO、Service 和 Controller 代码是一件非常繁琐的事情,里面存在着大量的重复工作,DataService 就是为了解决这个问题而生的。按照业务复杂程度的递进,可分为以下三种 DataService 的应用模式:
DataService 不是代码生成器,更直观地说它是把一切常见 CRUD 工作抽象化,然后使之可配置化的快速业务开发工具。
企业级的开发中包含大量的表单应用,与之对应的是数据库的表。虽然也包含关联表的较复杂操作和逻辑,但总体来说存在大量的重复工作——简而化之就是 CRUD 操作。首先是后台的业务操作,必须明确,抽象一个统一的 CRUD 服务与复杂多变的业务需求并不矛盾:能抽象的就抽象,不能抽象统一的就开放,无他尔。特别是写入操作(创建 or 更新)往往是可以做到统一的,而查询(SELECT)某种程度也能抽象(如分页,等等)。这就需要我们制定一套合理、高效的应用规则,实现上述设计之目标。与前端的关系,就是根据前端传入的参数来组装一条完整的 SQL,执行完毕把结果以 JSON 形式返还给前端。对于前端而言,虽然看到不同的 API 接口,但对于后端而言,只是一个 API 接口的入口,然后根据不同 URL 目录作分发而已。
前端的表单界面,实际没必要单独定制。在个性化跟统一化两边应要根据开发成本决定的。当采用统一化设计的时候,自动化生成表单界面变得很重要了。关于表单、列表 UI 生成器我们另外专题再讲。
前端表单做成统一的 CRUD 组件,字段名跟后端一致即可,提交参数为 JSON 传给后端统一的 CRUD 服务即可。
前端列表组件也是,关键在于复杂的 SELECT Query 查询,不同情况下组合的条件查询。甚至有种简单直接的办法,就是前端直接生成 SQL WHERE 语句传到后端,这并不是完整的 SQL,而是 SQL 片断,安全性更高(当然后端也要做好诸如 SQL 注入等的检查)。
退一万步讲,即使不使用统一的 CRUD 接口,也可以把数据服务作为一个 ORM 工具,或者说对 MyBatis 的进一步封装。实际上本作者也是大量这么使用的。这就是数据服务的另外一种模式:DAO 模式(Data Access Object)。DAO 后端开发人员都不陌生,在后端纯粹使用数据服务也是非常自然,无太大入侵的。最大的变化,则是之前在 MyBatis XML 写的 SQL 语句,如今却是放到数据库中保存 SQL 了,当然你不需要进入数据库修改 SQL(当然也不是不可以),而是在数据服务提供 GUI 中编辑 SQL,即时生效无需重启。有一套新的环境管理 SQL,底层仍是 MyBatis,而后端代码仍是程序员熟悉的 DAO。另外一点好处,就是既然在 Java 了,肯定是带类型的 Bean 实体 ORM,而不是 Map(当然用 Map 也是可以,看需要)。