Minya 分层框架实现的思考（三）：问题

最新推荐文章于 2024-07-27 12:15:16 发布

weixin_33785108

最新推荐文章于 2024-07-27 12:15:16 发布

阅读量92

点赞数

文章标签：移动开发

原文链接：https://juejin.im/post/5ad0373df265da237c694f78

版权

Minya 分层框架从某种程度上来说，基本达到了一些预期目标。回顾一下第一篇中的目标：

明确每一层的职责；

每一层专注于自己要处理的事情，而不用向外提供方法或回调来传输数据。View 层专注于视图的展示及用户输入的捕获；ViewController 简单维护 View 和 Store，更专注于页面的跳转、转场动画等操作；Store 层专心处理数据。将各层间数据的传输任务交由 pipeline 来实现，各层对象只需要监听其中的数据变化或往里面写数据就行；

另外，通过 pipeline 可以简化深层次视图数据外传的问题，避免通过层层 Delegate 将数据传输到 ViewController。
轻量化 ViewController，让其成为数据的中转站；

ViewController 不再需要详细地了解 View 和 Store 的细节，不需要作为 View 的 Delegate，也不需要调用 Store 的网络请求方法并在回调中操作数据；而是把更多的精力放到了页面跳转中。
将业务处理独立于一层，并可根据实际情况将业务细分到不同的类中进行处理；

所有的业务逻辑都在 Store 层来处理，如果一个 Store 处理的业务逻辑过多，可以将代码拆分到子 Store 中处理。
均分代码，确保一个类或文件的代码量不会太大。

然而，正如一个硬币的正反两面，有些方案带来便利的同时，也会引入负面的东西。

一次复杂数据传输流程的代码过于分散（正如上一篇的例子），可能会在多个类中，不直观，很容易就跟丢了中间流程。这对于调试和后期维护来说，是一件很不友好的事；
对单元测试不友好；
对于复杂的页面不够友好，如果说美团首页这种页面，需要构建复杂的 pipeline 层级结构，这可能会导致 pipeline 过于臃肿。实际上，如果处理不当，恰恰有可能导致复杂化 pipeline，对 View、ViewController 和 Store 的简化，最终可能实际上是转嫁了复杂性；
pipeline 的划分程度决定了 pipeline 类的数量，所以有可能引入大量的类，导致类爆炸。同样，Store 层及下面的 Service 和 Storage 也有同样的问题；
pipeline 中属性的设计顺序可能影响到操作是否能正常进行，如登录页面，需要先将 username 和 password 放入 pipeline 中，然后再设置点击按钮的 flag；如
KVO 对集合类型的支持不友好，pipeline 中需要额外的标识位来标识列表数据的变更；
降低了原有的依赖，而没有消除依赖，反而是建立了新的依赖，引入新的不确定性；
框架依赖于定义好的几个基类和接口，所有对扩展有一定的局限性；
Scene 对象减少 Objective-C 的 #import 操作的同时，增加了硬编码。这对于重构来说并不友好。

鉴于以上问题，以及 MVVM + RAC 的优越性，我们后来将整个技术栈切换到 MVVM + RAC 上，同时将 MVCS + Pipeline 这一套不成熟的框架开源，以供大家参考。

知识小集是一个团队公众号，每周都会有原创文章分享，我们的文章都会在公众号首发。知识小集微信群，短短几周时间，目前群友已经300+人，很快就要达到上限（抓住机会哦），关注公众号获取加群方式。

关注