Model再认识

按：自然，此文所说Model指的是MVC中的'M'。现在发现，以前对Model认识有些狭隘，导致在开发过程中本来是Model的东西缺归到了Controller中，导致各种别扭。为了解决这些别扭，又重新认识并发现了Model。

热，今年夏天以来最热的一天……

缘起

本周在开发“用户分享房源给经纪人”（本来应该实现经纪人分享给用户，但现在经纪人版还没有房源列表，故相反实现）时，在某个房源的“分享”按钮点击时，应该先弹出一个“经纪人列表”，用于从中选择目标经纪人。故事就从这个列表开始了。本来已经有个“经纪人列表”的Tab了，其实现了从server获取数据，并以TableView来展示。自然的，我想到了可以复用此实现。进一步尝试后发现，复用有两个明显的问题：

• 原来的列表中各Cell显示的内容现在列表并不完全需要，如该经纪人房源数、距离。实际上，现在只需要一个头像+名字就够了（关于此可以参微信“分享给朋友”弹出的列表）。所以，得需要根据这两种不同使用场景来决定是否需要显示。现在是两个地方用到了此列表，那么未来会不会还有更多地方用呢？如果是的话，那必然的结果是其中充斥了if-else对使用场景的判断。这显然不是一个“优雅”的办法。

• 就算代码复用了，实际上在弹出列表时是新生成了一个实例，并且，这个实例的数据还得从server取一份，这显然是不高效的做法——同一份数据，本地已经有了，还要从server取一份，太笨了。

鉴于此，我意识到我们需要思考“框架”层面的问题了。正是因为现在没有框架、没有框架意识，所以代码都是以“完成功能”为导向的，没有为复用留下空间。

思考

实际上我们已经遇到过一个相似的问题了：就是登录功能的复用。最初，登录、退出的请求也是写在Controller中的。在小明需要实现“自动登录”时（此时不需要界面）发现，没有办法复用Controller中的代码。难道再写一遍登录、退出请求？当然不！我们非常“不情愿”地把这些代码挪到了Model中（因为那时我对Model的认识就是开头说的“太狭窄”的阶段，认为Model就仅仅是数据），算是实现了复用。

现在这个问题看起来是同一个问题，是不是也得把取数据的代码挪到Model中呢？这样的Model是不是太庞大了？是不是应该再分成两层？我有点迷茫了，找不到理论支持……

曙光

脑子里冒出了融云的SDK，它分两个framework：RongIMKit+RongIMLib，前者是界面库，后者是通讯库。可以单使用RongIMLib，即不要界面。而且，RongIMKit的通讯能力也是调用了RongIMLib。也就是说，融云中除了界面部分，都在RongIMLib中了，那它不就是Model的角色吗？那是不是可以说，Model本来就是一个App的全部“实质”，不仅仅只是数据，还包括数据的操作、存储、管理等等。UI只是一件衣服，Model是衣服下面的身体。有没有UI，身体都是功能完整的，而且UI可以随时换。如果用这种方式去定义Model，似乎就不会有“Model过于庞大”的顾虑了。

Linux

我觉得，kernel就是Linux的Model，各种KDE、shell，都是UI。UI是各异的，但kernel是唯一的、完整的。

对我们的启示

如果我们也实现一个完整的、真正意义上的Model，将意味着：

• TA是我们App所有功能的“无UI”实现（这个有点绝对，一些非常简单、直接的功能点就在UI部分实现了，如版本号之类）
• TA将存储所有从服务端、本地读取的数据，并且同样的数据只需要请求一次，在内存中只占用一份空间，绝不会浪费【开头的第2个问题得到解决】
• TA和UI（也即View+Controller，下同）有清晰的“楚河汉界”（你看融云是两个framework，耦合性是多么低），各自独立，故可分别在需要时进行重构（只要保证Model提供的接口不变）。
• UI部分将会非常轻薄，依赖Model提供的接口实现，仅引用Model中数据实体（而不存储）
• 最重要的是：我们可以对Model进行单元测试。对于Model来说，“单元测试” 和 “UI部分”的角色是相同的：都是Client（即依赖Model提供的“服务”做点事）。

这些理由，足以诱惑我们尝试一下了吧？

（关于开头第1个问题，那属于UI部分代码复用范畴，不在这里说了）

总结

理论在实践中被大师提出来，然后，我们在实践中理解它。

【Updated】

第一版中，最后一句，“大师”用了引号，本意是强调，却容易引起误会，故去掉引号