- React:重分抽象了展示的过程,展示就是把数据放到View上的过程,View变化一定是某个数据变化。所以这种变化可以以状态机的形式存在,所有影响View显示的数据作为一个状态。通过对于状态的kvo,可以实现更为高层次的数据绑定,并不是一个View对应一个String这么简单。其实data-binding都是一样的,但是抽象成状态机会非常容易理解。
- Flux:又是Facebook做MVC抽象的一个设计。痛点在于原有的MVC模式上,C负责了V和M的更新,导致C的代码不好维护。
抽象来说,App的主要目标都是展示操作数据,分以下功能模块(以登录为例):
- State(View Model):唯一的对应着一个页面状态,React中的state,状态间是互斥的。如输入框状态(页面显示什么内容)、RPC状态(进度展示)
- View Biz:显示相关的逻辑。如对于输入,是显示明文还是点点点
- Biz:数据处理和业务逻辑。如处理RPC校验账密结果
- View Event:UI的交互事件。如点击登录按钮
- Event:业务逻辑事件。如RPC返回结果了
- View:页面,纯视觉元素(React和Flux都没有特意把这个东西独立出来,都是揉在了View Biz里)
整体来说,[View] Event会通过Biz改变State,State通过View Biz改变View。同时View又会发出View Event。
Flux就是按上面的逻辑分层。Store对应着Biz,Action对应着两种Event,View对应View和针对本View的View Biz,Controller-View对应着整体的View Biz。
为了解耦: - 所有层间事件传递都是以注册+回调的方式进行(这是解决痛点的地方)
- 以消息队列的方式进行事件的传播(Dispatcher的作用),不会有过多的成串调用(callback中调callback)
- Redux 只有action、reducer和store。看起来就是flux的变种:
- 没有消息队列
- State不可变
- reducer对应着flux的store,store对应着flux的dispatcher
- 强调了一个页面一个state和reducer的回放作用,其实Reducer就是一个Command——一段逻辑的封装
- VueX同样是单中心Store、单线数据流、事件驱动。特点在于把业务逻辑也分了层:Actions和Mutations,Action是业务逻辑,Mutation是数据逻辑。没见过大项目,不知道这个分层好处在哪,但是代码似乎会更好维护。
- Clean Architecture:是一个架构的集大成者,做到最大化的隔离变化。看了一下Android10的例子,可能并没有get到核心点。按照UncleBob的说法,要有四层:
- Entity:最核心不变式。个人看来可能不能反映到程序上,因为有些不变式是领域模型。或者可以强行说数据驱动的程序中的数据。这层由于没有多少逻辑在,所以什么都不依赖
- UseCase:业务逻辑。必有的部分,是一些方法或模板方法,做成了最核心的原子业务功能,比如RPC之类的。这层会有模板方法的回调接口声明,只依赖Entity
- Interface Adapters:交互逻辑,对应着Presenter(UncleBob说对应着整个MVP,这样来说,此处的M是ViewModel不是DomainModel,V是手写View的显示逻辑)。是整个程序功能的流程控制,相当于将核心业务逻辑(UseCase)粘到一起的粘合剂。这里面会有存储注册接口。
- Frameworks&Drivers:外围系统,adapter模式的实现层,协调外部系统和上几层中的接口要求。
那些年我看到过的牛逼设计
最新推荐文章于 2021-12-30 09:00:53 发布