.Net 低代码框架评价——火凤凰框架与其他框架

目录

代码结构

代码结构简化

难以与DDD结合

生成代码

集成能力

自定义表单——低代码的代表

慎用自定义表单，便捷的东西也是有代价的

数据源——更简单的视图表单

自研流程引擎

扩展性差

流程不可靠，数据流不正确

小bug防不胜防

RABC权限管理系统

组织架构、菜单管理、定时任务、实时通知……

应对变化的能力

流行框架对比

Furion

演进式的框架

框架对比图

如果要换框架

目前使用火凤凰框架遇到的问题讨论

---

本文主要介绍.Net 低代码前后端框架，分析了博主公司自用付费低代码框架火凤凰Phoenix的优劣及使用经验，并对比主流开源框架Furion。 

代码结构

代码结构简化

实体和接口层结合，比三层更简单

难以与DDD结合

传统的面向db开发，根据db结构来生成代码

因为model层的设计，难以与ddd结合，难以往更大的架构发展

DDD：面向业务开发，充血模型，高内聚低耦合，拆分

生成代码

• Model属性全为可空类型，配合生成查询语句可以比较好地实现全参数条件查询

• 旧版的生成的代码用sql拼接，新版多表关联也是用sql拼接，变动表结构时容易出错漏

• 代码检测出非常多sql注入漏洞，包括生成代码和框架基础代码

• 建议代码生成器只生成单表代码，利用对象继承、[Column(IsIgnore = true)]、ORM能力，按需编写多表代码，更可控

集成能力

自定义表单——低代码的代表

做不到真正意义的零代码

表单生成需要先建数据表

慎用自定义表单，便捷的东西也是有代价的

• 绑定字段的时候比较麻烦：

界面设计 -> 自定义表单/生成前端代码

自定义表单 -> 功能设计 -> 菜单页面

自定义表单 -> 流程模板

（尤其是用代码生成前端表单，再绑到流程里）

• 通过配置，链路变长，效率变低（字段多、数据量大的时候）；自己写或者生成代码更直接，运行效率更高

• 后期的部署可能要进行语句级的更新，麻烦且容易出错；而代码至少会跟着程序更新上去

数据源——更简单的视图表单

 

真正的低代码应该是我说出我的意图，给出最核心的东西，框架帮我实现剩余的东西

自研流程引擎

扩展性差

• 如果要在流程数据中返回一个业务字段，比较难，尤其是在分库的情况下需要跨库查询。

    而且不能直接改写接口，因为低级的框架模块无法引用高级的业务模块，只能在业务模块重写接口，前端再调新的接口。

---

• 流程里的用户局限于系统用户表中的用户，比如小程序端的市民就没法直接参与

流程不可靠，数据流不正确

小bug防不胜防

• 流程允许多个角色审批时，拥有多角色的用户时会收到多条任务

• 流程设计在正式环境保存会不了

    本来流程越长，流程的框架越有价值，但现在是bug越多

RABC权限管理系统

• 可通过权限控制菜单、表单、按钮

• 但自己写的页面的按钮想接入权限比较难，得在数据库加入配置信息

• 一般只会用菜单级别的权限控制，按钮级别的形同虚设

• 数据权限是限制

• 角色管理、用户管理也有bug

组织架构、菜单管理、定时任务、实时通知……

• 有配套的前端界面

• 多少有点不容易发现的bug，让人猝不及防：

    定时任务在部署后不会自动启动，即时消息没有成功发送等bug

应对变化的能力

配置	字典、菜单、权限	部署时需要注意，容易出错漏
表结构	sql拼接、实体类	如果是绑定了自定义表单、功能设计，要重新绑定一次
引擎	工作流、表单	可以在界面上修改，但改动必须足够简单，如显示/隐藏列

流行框架对比

Furion

Furion	火凤凰
GVP项目，遵循 MIT 开源协议	低代码，收费项目，已过期
非常完善的文档，包含各种最佳实践	文档不齐全、没有标准，很多东西要靠自己试，特别耗时间（如流程）
活跃的社区，共同贡献错误修复和改进	迭代速度较慢，有些功能亟需完善，但过了收费期不能再更新
所有底层功能 100% 测试通过	没有单元测试，不可靠，bug较多防不胜防
扩展性好，可以参阅文档，如实现多租户	使用简单，但扩展不容易，如工作流
分布式缓存、分布式ID、事件总线、分布式作业调度	不具备面向分布式的能力
提供多种扩展包、手脚架，撘配CodeFirst，能按需快速初始化	初始化比较麻烦，需要用脚本初始化数据库
集成动态WebAPI、任务队列等特性	集成权限管理、组织架构、工作流、定时任务、企业微信等，并集成配套前端

如果想Furion也集成更多基础能力

1.4 开源案例 | Furion

演进式的框架

如果可以预示到项目未来会发展为大体量的项目， 可以选择演进式的框架，面向微服务的单体架构

如：DotBPE.Rpc

GitHub - xuanye/peas: 模块化的服务架构设计的伪代码

• 使用DDD代码架构

• 内部服务通过RPC来调用

框架对比图

既然我们的项目规模不大，那我们就追求极致的开发效率、更快地响应变化、更稳定更少bug

如果要换框架

• 可靠性

• 初始化速度

• 应对变化的能力

• 扩展性

目前使用火凤凰框架遇到的问题讨论

1. 页面缓存没有及时清理，打开新页面时常常还显示着上一个页面的内容

2. 因为样式名称重复，dev环境没问题，但build完后就出现样式错乱

3. 为了兼容自定义表单、流程，需要加入更多的措施，写更多的代码，提高了复杂度，更容易出错