MVC架构中的Model

进入正文前吐槽下stroryboard，最近碰到一个通过StoryBoard在uiviewcontroller上添加UITableView，导致自定义Cell中的UILabel无法多行显示的BUG，具体什么原因导致的我也说不清了，最终还是通过全代码添加UITableView规避了问题。

最近研究PureMVC架构，觉得对MVC中Model的认识有了点进步，有必要在这里记录一下。本文以一个测试项目作为例子来具体介绍下我所理解到的Model层。

demo界面

这个测试Demo的功能比较简单，主要目标是方便日常工作中的具体测试。
从Demo的界面上我们大致可以想到，该工程会涉及到Platform/Company/App/Product这样几个Model，且每一个具体的Model都有着它自己独特的数据结构。

业务与数据的耦合

Model是所有业务逻辑操作的基础，业务逻辑操作就是在Model数据的基础之上进行各种各样的运算并得出结果展现在UI界面之上。MVC架构中，一个M能够对应着各种各样的V与C，也就是说业务间可以共享Model。对于这一点如果不加以有效的约束，M就会暴露在整个工程代码之中，导致了Model与各种业务间的强耦合关系，这样会非常不利于业务的扩展与迁移。如何实现业务与Model之间的解耦呢，PureMVC给出的解决方法是Proxy。

Proxy

一个客户不想或者不能直接引用一个对 象，此时可以通过一个称之为“代理”的第三者来实现 间接引用。代理对象可以在客户端和目标对象之间起到 中介的作用，并且可以通过代理对象去掉客户不能看到 的内容和服务或者添加客户需要的额外服务。

PureMVC通过使用代理来向具体的业务暴露它们需要的数据，而代理会保存有Model的引用，这样就可以取到具体的业务数据了。因为每一个具体的业务的关注点各不相同，数据的UI展现格式也不一样，将数据的格式化与转换操作放置在Proxy中是最合适不过的了。

通过Proxy这种模式，业务就只会与它自已的Proxy打交道并专注于处理自己关心的数据，不同的业务都与它们各自的Proxy交流数据，因此业务就不在关注底层具体的数据结构，进而解决了数据耦合这一问题。

两个Model

第一个Model当然指的是上面所说的最底层、最基本的Model，如Demo中的Platform/Company/App/Product等。

选择平台

第二个Model在哪呢？上图中要选择平台的名称，这个业务的数据我们可以通过Proxy从Platform中取platformName这个字段即可。但仅仅取这一个字段可以满足需求吗，如果仅仅做显示，这一个字段是足够的。但Demo中我们可以看到还有其它业务，比如根据具体的平台获取平台下面的公司及公司下面所拥有的应用信息等业务。这些业务我们还需要platformId这样一个字段。也就是说在这个页面里我们至少需要通过Proxy获取platformId与platformName这两个字段，那么获取到的这样一个结构在某种意义上不就是一个Model吗？只不过这个Model比第一个Model少了很多对业务没有意义的其它字段，仅仅只是因为这个业务而存在。

为什么要提出这样一个概念呢？因为一开始我觉得这样很繁锁，因为一个解耦的目标多出了许多Proxy与Model，多出了许多将两个Model互相转化的代码。后来仔细想下，这可能就是程序模块化所必然要付出的代价吧。