New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
如何实现 Model 嵌套(模块化)? #610
Comments
业务上是这样的, 这种情况的话,只有单一一层 model 会显得很局促 |
当然实际上也可以在namespace上区分,然而目前namespace会直接作为state名(不能使用 |
没太明白 |
文档看下来,model 物理上只有一层,如果 model 数量极多的话,很有可能会有 namespace 重名的冲突(尤其是大型项目,一些 model 的语义是一样的),此时可能只好在 namespace 上,显性得加上 prefix 作为 模块 的区分。 所以想问下 是否有更好的 model 嵌套 或者 模块化 方案? |
state里都不建议嵌套太深,你要是还把model嵌套就更复杂了,感觉设计就有问题吧。 |
这个问题大致明白意思了,昨天我们讨论了一下,主要是model所代表的含义,有两个倾向:跟着视图划分、跟随业务实体划分。 从目前的设计来看,应当是跟随视图更合适一些,因为各model的state都是隔离的,model里面的东西都是跟着自己的state走的,从这个角度,确实是跟随视图更好,这种情况下,model的含义是view model。 但是这么以来,model所使用的那些业务上的增删查改effect,可能在每个使用到的model都要存在了,例如: 存在视图ABC,业务实体XYZ,其中: A使用了XY的CRUD 我们的model要跟随ABC视图来设计,必然在其中会存在一定的冗余effect,比如Y同时存在于AB中,代码上可能有冗余。从另外一个角度考虑,Y在AB中的使用,本身就不应当考虑复用,要复用的调用过程应当放在更下一级,也就是service。 于是,组织结构就成为:
而modelA的结构:
modelB的结构:
稍后我来写个比较业务化的demo,并且给出一些场景的使用建议 |
@xufei 就需要民工叔这样的指导! |
@xufei 可以学习下 你的demo吗?最近也在发愁这个事 |
@xufei demo有了么? |
1 similar comment
@xufei demo有了么? |
我觉得 业务Model 和view model 都要有比较合理些,比如 当前用户可以有一个user model 来全局处理, |
@liSong5713 用户列表点击进去的用户详情列表,用户详情里面点击进去的钥匙管理这些是否应该放在同一个user model里面 |
@lwbGH 这要看你model职责,user model 可以是当前登录的user的基本常用的信息,如果想要改用户详细信息,比如该用户操作的日志这样信息完全可以另一起model ,我认为model划分在于一点: |
有很强的模块化需求,
如果只有一级 model 的话,可能 model 会很多,不利于模块化
不知道如何实现 Model 模块化?
The text was updated successfully, but these errors were encountered: