前言
作为一个并不是很有经验的开发者而言, 不敢妄论架构二字, 只是对目前市面上一些常见的架构中的一小部分--Model部分--有一些思考. 这些思考也是基于我在实际编写代码中所遇到的问题所引发的. 因此我想抛出这个问题, 希望大家一起来探讨.
问题
市面上比较流行的两大应用开发架构是MVC和MVVM, 让我很奇怪的是, 无论是MVC还是MVVM, 都对Model有无以伦比的"洁癖", 也就是说在model里面只描述业务对象, 坚决不加入任何其它代码. 为什么呢? 我思考了很久, 没有找到能让我认同的观点, 因此我在下面的篇幅中会阐述我对iOS应用架构中Model定位的理解.
想法
在继续讨论这个问题之前, 我先说说个人对什么是好的架构或者好的代码的一点点思考, 仅仅是个人的思考, 不代表说一定正确.
每次我们谈到好的架构或者代码的时候都会说: 通俗易懂, 有拓展性, 易修改, 足够健壮等等等等. 但是在我看来都是表现, 我认为好的代码归根结底就一点--高复用性. 如果代码写的很晦涩不好修改, 那么就无所谓复用了, 如果有足够的人力物力迟早会被人重构掉;
如果代码拓展性不好, 不能适用新的业务场景, 那么就需要重新造一个新的类出来实现, 自然也没有复用度可言;
(当然, 并不是说好的代码或者架构就一定是复用度极高的, 这中间有一定的平衡, 一味追求高复用度最后造成的结果就是接口很难用, 这个问题不在本题讨论范围内)
作为业务描述的Model, 复用度会高吗? 从我的经验来讲, 基本不会有复用的, 除非一种情况就是外面是summary里面是detail的情况, 这种情况一般会detailModel继承summaryModel来复用一部分代码. 但是这种情况不影响继续讨论这个问题, 因为本质上是属于同一个业务, 我所要表达的是, 既然绝大多数的情况下, 我们不可能把一个业务的Model复用到另外一个业务上, 那么为什么不把一些额外逻辑写在Model上面呢?
这个想法起源于MVVM这个架构, 为了解放Controller, MVVM中引入了ViewModel这么个概念, 但我个人认为, 只要把一部分逻辑写到Model中是可以减轻一部分Controller的负担的并且不用担心会有其它副作用, 例如:
- 提供外部展示的内容: 例如大多数回复的展示都是回复者+时间, 显然服务端不会一次返回给我们, 为什么我们不在Model中暴露一个借口叫replyText来组装这部分内容提供给UI层展示呢?
- 还是对外展示内容: 我们经常会对一个字符串有加粗或者其它颜色的展示需求, 为什么不在Model中提供一个attributedTitle的接口来对外提供需要一个AttributedString来展示这部分内容呢?
- 提供动态变化的内容高度: 服务端返回的内容不固定, 占用的高度也不固定, 在不使用自动布局的情况下, 为什么不在Model中计算高度呢? 特别是tableview中, cell是变高的情况, 因为cell的复用有可能导致一些高度也被复用的情况, 为了解决这种情况, 我看到不少人会缓存一个Array来保存高度, 而如果model中有能力直接返回高度就不需要在controller或者dataSource中写这一部分逻辑了, 且不用担心复用的副作用.
......
以上几点是我经常在Model中加入的逻辑, 这么做的好处是, 无论Model有什么变化都可以在Model内部解决, 比如发现自己有些属性名命名不太对, 有个展示的内容需要修改, 都不需要修改调用方的代码, 直接内部修改即可.
所以我个人是很乐意在Model中加入一部分业务逻辑代码的, 作为业务描述的Model, 多承载一些业务逻辑也未尝不可. 如果只是为了所谓的保持Model层的清洁, 那么我宁愿Model层与UI看上去有了那么一丝丝关系, 也不愿意把这些逻辑再加入到原本就需要承载更多逻辑的controller或者dataSource中了.
讨论
以上只是我个人的看法, 目前我一直在使用这样的Model在开发, 暂时没有遇到其它的副作用, 所以抛出这个问题想让大家一起来讨论这个做法的是否有所不足, 还有没有更进一步的地方.
