Dva: 如何实现 Model 嵌套（模块化）？

业务上是这样的，
比如 app 里有5个业务相对独立的产品，每个产品都有相对独立的 model。

这种情况的话，只有单一一层 model 会显得很局促

当然实际上也可以在namespace上区分，然而目前namespace会直接作为state名（不能使用 . 等特殊符号）

只有单一一层 model 会显得很局促

没太明白

@codering

文档看下来，model 物理上只有一层，如果 model 数量极多的话，很有可能会有 namespace 重名的冲突（尤其是大型项目，一些 model 的语义是一样的），此时可能只好在 namespace 上，显性得加上 prefix 作为 模块 的区分。

所以想问下 是否有更好的 model 嵌套 或者 模块化 方案？

state里都不建议嵌套太深，你要是还把model嵌套就更复杂了，感觉设计就有问题吧。
问题没太懂，能否给个简易demo？

这个问题大致明白意思了，昨天我们讨论了一下，主要是model所代表的含义，有两个倾向：跟着视图划分、跟随业务实体划分。

从目前的设计来看，应当是跟随视图更合适一些，因为各model的state都是隔离的，model里面的东西都是跟着自己的state走的，从这个角度，确实是跟随视图更好，这种情况下，model的含义是view model。

但是这么以来，model所使用的那些业务上的增删查改effect，可能在每个使用到的model都要存在了，例如：

存在视图ABC，业务实体XYZ，其中：

A使用了XY的CRUD
B使用了YZ的CRUD
C使用了XZ的CRUD

我们的model要跟随ABC视图来设计，必然在其中会存在一定的冗余effect，比如Y同时存在于AB中，代码上可能有冗余。从另外一个角度考虑，Y在AB中的使用，本身就不应当考虑复用，要复用的调用过程应当放在更下一级，也就是service。

于是，组织结构就成为：

  a
  b
  c
service
  x
  y
  z

而modelA的结构：

{
  effects: {
    *x() {
      yield call(serviceX);
    },
    *y() {
      yield call(serviceY);
    }
  }
}

modelB的结构：

{
  effects: {
    *y() {
      yield call(serviceY);
    },
    *z() {
      yield call(serviceZ);
    }
  }
}

稍后我来写个比较业务化的demo，并且给出一些场景的使用建议

@xufei 就需要民工叔这样的指导！

@xufei 可以学习下 你的demo吗？最近也在发愁这个事

@xufei demo有了么？

@xufei demo有了么？

我觉得 业务Model 和view model 都要有比较合理些，比如 当前用户可以有一个user model 来全局处理，
其他的组件如果涉及了当前用户信息，可以直接connect user model 就好了。具体还要看业务需求

@liSong5713 用户列表点击进去的用户详情列表，用户详情里面点击进去的钥匙管理这些是否应该放在同一个user model里面

@lwbGH 这要看你model职责，user model 可以是当前登录的user的基本常用的信息，如果想要改用户详细信息，比如该用户操作的日志这样信息完全可以另一起model ，我认为model划分在于一点:
平级组件状态的共用程度，如果一个简单页面对应一个页面级model，反而会复杂化

当然实际上也可以在namespace上区分，然而目前namespace会直接作为state名（不能使用 . 等特殊符号）
.不可以做key，可以用_，目前我们就是在namespace做约束，models下可以按视图、业务分模块，但namespace按照"文件夹_文件名"做约束。