从 MVC 引出的一个想法 —— DB as Application

邹业盛 2017-11-21 14:47 更新
  1. 缘由
  2. 很多时候我们需要的是什么?
  3. 还有其它的例子
  4. DB as Application ,本质是数据

1. 缘由

最开始的时候,有人在 CPyUG 邮件列表中提出 https://groups.google.com/d/msg/python-cn/nurVNl_ctto/BOYuyX07AgAJ

 但是最近写项目的时候总是觉得很不爽,曾经的后端是 MVC 三层,现在 V 移除了,剩下 MC 两层,我慢慢也觉得 C 层显得多余了。
 现在逻辑基本上都在前端写了,那后端留下什么呢?我认为在 Model 层上面加上权限控制、条件查询、数据校验以及分页功能就完全足够了。

这里个人补充一些背景。大体上来说,目前的 Web 开发方式,因为前端对交互效果与用户体验的重视,以及对多设备端的现实需求,而慢慢趋向于“前后端分离”的一种方式,简单来说,后端响应纯数据,剩下的页面展示与交互完全由前端处理(而不是之前的后端渲染一个完成的 HTML 页面的方式)。这就是上面提到的,“MVC 中,V 移除了,只剩下 MC 两层”。

再看 MC 这两个抽象层,同时联系后端业务系统中,一般都会有 ORM 类的工具, M ,数据模型的定义,一般是 ORM 中的对应概念,很多时间,又是与 DB 中的“表”对应的。 当 M 定义之后,剩下的 C 层做的事,其实就是上面提到的,实现一些权限控制,条件查询,数据检验,等功能就足够了。

2. 很多时候我们需要的是什么?

前面提到的,其实就是大部分信息化需求所面临的场景。

在这个层面,我们当然不能谈什么用户体验,谈交互,这些细节还需要做很多的事,但是,上面说的“足够”的,确实是对“数据本身”来说,足够了。

事实上,在实际的应用开发中,一套 ORM 机制,在 Model 定义之后,直接生成对应的 RESTful 服务,甚至自动产出相关表单,这些功能都不是难事。更进一步,一套完整的数据管理后台,这也是已经实现了的,比如 Django 的 admin 后台。

Django 之前,它的 admin 后台功能是它的一大亮点,因为它几乎 0 成本地解决了一大堆问题,但是这还远远不够。然而,我们的目光都放在这个 admin 后台可以如何去定制的时候,却忘了,这个 admin 后台本身,是建立在一套 HTTP 服务之上,而这一套 HTTP 服务,你不需要写一行代码。

再说得明白一些, DB + 专门的应用层封装 = 完整的数据服务, Django 的 admin 后台功能,已经体现了它的可能性,与实际的价值。但它还留下了定制化的问题。

所以,当我们在说数据库,或者持久化存储的时候,实际上我们需要的,首先是一套能力,这套能力需要有一些上层应用的载体,但是,并不是说一定要有一个完整的应用层(也许像 Django 的 admin 这类,顺便一个能看的,就足够解决问题了)。简单如 Access / FoxPro 这类产品,复杂如“企业级”的那些复杂 SQL ,跳出互联网行业的我们习惯把数据层做薄这点来看,在其它很多领域,很多场景下,数据存储,与数据应用其实并不是很得那么清楚的。

很多时候,我们想直接把一个 DBMS ,包装一下就可以给到用户,来达到“数据应用”的目的了,但是,这个功能强大的 DBMS 却无法被“包装”。

3. 还有其它的例子

依托于 Elasticsearch 的 ELK 方案中, Kibana https://www.elastic.co/cn/products/kibana 是一个纯前端产品(我的认识来源于 4 年前,最新的技术结构也许有变化),它实现可视化的数据来源,是 Elasticsearch 的 HTTP API,因为 Elasticsearch 有 HTTP API ,所以才能有一个跑在浏览器中的 Kibana 。

Clickhouse https://clickhouse.yandex/ 是 Yandex 开源出来的 OLAP 方案,它也本身提供了 HTTP API ,所以自然地,纯前端实现的 GUI 管理工具, tabix https://tabix.io/doc/ 开箱即用。

传统地,对于 Postgresql 来说,它的 pgAdmin https://www.pgadmin.org/ 的新版本,也已经从桌面端改为 Web 端的,但是 pg 并没有提供 HTTP API ,所以这个 Web 端自己要在中间做一层逻辑“转发”的工作。

4. DB as Application ,本质是数据

不管 pgadmin ,或者是 mysql-workbench 这种管理工具,还是 Kibana , tabix 这类更上层的数据展示工具,也许它们功能的侧重点不同,但是它们本身,都是依赖于数据库中当前的数据,并且以一种合适的方式提供了这些数据的访问。而我们业务系统中,所谓的“业务层”,又何尝不是在重复地造这个“合适的方式”来提供数据访问呢?

Mysql 有 `show tables` 这类语句, pg 也有自己的“元数据表”,这些数据库系统只要加一个 HTTP API 的套子,就可以直接作为“应用层”方案。

无论你是否承认,数据库与应用层,在面对问题时,本身的处理方式也并没有什么不同。用户,权限,角色,大家都一样。应用系统有“方法”,数据库有“存储过程”,有“视图”。应用系统有“hook”,数据库有“触发器”。应用系统有“数据校验”,数据库有“约束”。甚至在更低层的一些“原语”中, pg 声称自己是“面向对象”的,表之间可以“继承”。

回到最开始的问题, MVC 这套东西, V 先不考虑, M 在数据库端是现成的, C 的能力在数据库端可能通过各种机制弥补一些,数据库只差一个 HTTP API 的套子。

而 pgadmin 这类另外造了套子,面对同样的数据却只将它用于“数据库管理”,何尝不是一种资源浪费呢。

Elasticsearch 对接的 Kibana ,把数据上升到了应用层面,也许限于“可视化”只是因为 Elasticsearch 本身并没有深入业务系统。

不管,在 DB 与 用户端之间,是否存在单独的一层“应用层”,其间流动的数据都是一样的,如果关系数据库能像 Elasticsearch 或 Clickhouse 一样,直接提供 HTTP API ,那么很多的“应用层”都没有重复建设的必要了。而对接一个数据库产品的 HTTP API 接口,像 Kibana 这样的东西,也绝不限于“数据可视化”这个范围。那时, Django 的 admin 也只是最初级的应用形态,“数据可视化”是顺带附赠的能力。

剩下上层面对数据时的定制需求?只是一个搭积木的游戏而已。

(有一段演示视频,目前不方便公开)

这套积木针对一个业务去做,它的能力就是这个业务,而把它针对一个数据库去做,它的能力就是这个库的数据,那将不限于任何业务,也就能用于任何业务。

©2010-2017 zouyesheng.com All rights reserved. Powered by GitHub , txt2tags , MathJax