基于re-frame的大型项目无app-db直接调用是否符合预期？

1. 这种情况完全符合预期 #

Re-frame的核心设计逻辑就是数据隔离与单向数据流，官方文档本身就推荐尽量避免直接操作或访问app-db。对于服务付费客户的大型专业项目而言，为了保障代码的可维护性与可追踪性，团队通常会严格遵循这种约束，所以看不到对app-db的直接调用是非常正常的现象。

2. 这是非常良好的实践（但并非唯一可行方案） #

• 提升可维护性：所有对app-db的访问都通过订阅（subscribe）和事件（reg-event-db）封装，后续如果需要修改数据结构，只需要调整对应的订阅或事件实现，不用在代码中到处修改零散的直接访问逻辑。
• 增强可测试性：订阅和事件的逻辑大多是纯函数（或可隔离的逻辑单元），可以单独编写测试用例，无需依赖整个app-db的完整状态。
• 明确数据流走向：所有数据变更都通过事件触发，所有数据读取都通过订阅完成，让整个应用的数据流清晰可追踪，在大型团队协作场景中能有效减少逻辑混乱。

当然，在一些极端场景下（比如超小型项目快速开发、临时调试代码），偶尔直接访问app-db并非完全不可行，但在大型付费项目中，严格规避直接访问显然是更稳妥、更专业的选择。

3. 并非只能通过reg-sub和subscribe间接访问，但这是官方推荐的标准方式 #

Re-frame确实提供了re-frame.core/get-app-db这类可以直接获取app-db的函数，但官方强烈不建议在业务代码中使用。除了订阅之外，还有一些其他的间接访问方式：

• 在事件处理函数中，reg-event-db的handler会接收db作为第一个参数，这是事件内部处理数据变更时的标准方式，但也仅限于事件逻辑内部，不会对外直接暴露app-db。
• 对于跨组件共享的复杂逻辑，可以使用reg-sub-raw创建更灵活的订阅，但本质上依然是对app-db访问的封装，而非直接操作。

总结来说，大型项目中完全不直接使用app-db是贴合Re-frame设计思想的最佳实践，既能保证代码的健壮性，也能大幅提升团队协作的效率与代码的可维护性。

内容的提问来源于stack exchange，提问作者Pedro Delfino