精读《如何抽象可视化搭建》

[ascoders]

平时一部分工作重心在 BI 可视化搭建，所以准备出个系列，把这部分心得分享一下。这一篇从理论上思考一下为何要抽象可视化搭建，以及如何抽象。

---

精读《如何抽象可视化搭建》

[ecnatsiDehTog]

请问原文可以分享吗

[ascoders]

@ecantsiDehToG 没有原文，纯原创。

[kewab]

看到这个我竟然想到的是蓝湖设计稿直接变为代码

[proclml]

从知乎来的，本想在知乎回复，但想到那边戾气可能会很重，觉得还是这里让人心安。
最近在做低代码平台开发，感觉和作者说的东西应该有交集，有些问题想不通，看能否获得交流。

1. 是否应该支持类似“调用后台代码”的功能？功能描述大概是：用户可以上传一段后台代码，后台语言可能根据本平台能力为准。其实我更倾向于支持rpc调用功能，因为反正都是写后台代码，以一种更舒服的方式去调试、构建、调用更好吧。
2. 如何解决“定义js函数”这类功能在书写上的约束问题。常见的做法都是放一个富文本编辑器在前端，但这样弊端非常多，难以调试、难以报错。
3. 如何解决数据更新问题？迭代一些功能之后，如果涉及到数据库的改动、数据的改动，如何在上线时平稳更新？

若有高见，希望不吝赐教，非常感谢

[a243065157]

收到

[ascoders]

@proclml 尝试回答下：

1. 取决于这个平台的用户，如果用户是开发者，直接上原生代码是最好的。如果用户群体向普通用户拓展，需要简化设计，比如 PowerBI 在查询能力抽象了 DAX，PowerApp 的 powerFX。
2. 我能想到的约束，一个是沙盒，一个是语法封装。语法封装类似 powerFX，只要把底层 js 调用干掉，语法自定义，理论上从编写到解析，再到执行可以 100% 受控，调试理论上可做到断点。
3. 前端的话就是数据迁移，组件要有版本号，支持数据订正。后端刚一点也可以数据订正，如果私有化部署可以在停机维护时刷库，写个 sql 脚本跑。后端软一点就是平滑升级，旧接口保留，监控数据，降到某个数量后订正完下线，实现上甚至可以抹平对接到新的数据表，提前做好迁移。

[donkeylmx]

@proclml 你好：
我最近在做前端低代码开发，在我做的经验之上可以尝试回答你的问题：

1. 我觉得应该支持，代码的逻辑是很难去抽象的，但是由于我目前的低代码工作，由后端主导（后端是打算做一个零代码平台），零代码的核心是定义若干元数据组件，每个组件都有相应的后端业务（数据库字段拥有指定业务），对于复杂业务他的计划是对复杂业务进行分解，用多个元数据组件进行业务代码替代（数据库添加多个字段来实现一个字段的复杂功能）。
   2，3 参考这位的发言 @ascoders

[bcguan2008]

逻辑层稍微有点抽象，我可以这么理解么

1. 在逻辑层的前面，应该还有一个模型层，模型层负责定义 元数据，画布/组件信息（可以抽象成 document/node/props 各种模型）；
2. 作者所说的逻辑层，其实是对这个模型的操作。

[ascoders]

@bcguan2008 嗯，包含这些，但是这些的超集，还会有很多功能加入逻辑层。我觉得可以这么理解：业务层可以用逻辑层提供的原子能力，很方便的组合成业务要的任何能力，比如利用逻辑层提供的联动能力，快速实现业务层自定义的联动协议。

[samwangdd]

@ascoders 文章中有一些专业术语想请教下：联动、取数、冻结 这些操作是什么意思？常见的场景是什么？

平时一部分工作重心在 BI 可视化搭建，所以准备出个系列，把这部分心得分享一下。这一篇从理论上思考一下为何要抽象可视化搭建，以及如何抽象。

精读《如何抽象可视化搭建》

[ascoders]

@samwangdd 联动：根据某个图表查询结果作为其他图表的筛选条件；取数：查询 sql；冻结：性能优化的术语，组件不再响应任何事件。

[zzbo]

@samwangdd 联动是指不同组件之间的通信和调用。

[limerickgds]

读完文章之后，感觉逻辑层的定义等于视图渲染层吗？还是说包含业务逻辑的？如果包含，业务逻辑如何统一维护和被执行？