古人有句话说“十年河东、十年河西”，前几年在 Android 开发上，MVC 的设计一直是众人谈论的重点。但是随着时间的更替，MVP 似乎开始热了起来，连 Google 自家的示例中都提供了 MVP 的设计样板，MVC 反而不在示例之列。
这让很多人会兴起一个疑问是：
MVC 和 MVP 我该选哪一个？我真的该弃 MVC 改投 MVP 的怀抱吗？
面对这样的一个问题，让我想到了星爷电影中的一句台词：
争什么争，把两样掺在一起做濑尿牛丸不就得了，笨蛋！
听起戏谑，但却不失为一个设计上可以思考的方向。MVC 和 MVP 的示意图相信很多人可以信手捻来，并且解说得头头是道。但各位可曾想过一个问题，这些示意图转成实际的 Class Diagram 之后，都只能各自对应到一个 Class？如果把 V 视为一个 Sub-System，在设计上是不是可以有更多的可能性？
举个例子，下面的这个示意图是以 MVP 为主体，然后 View 的角色以 MVC 代换进去。
MVP + MVC
同理可证，如果不想要套用 MVC，那可不可以用 Facebook 的 Flux 架构代入？好像也没什么不可以，换完之后就像以下的示意图：
MVP + Flux
如此设计上的变化，带来了某种程度上的弹性。假设今天有个系统原本是在 App 上开发的，但需要移往 Web 平台。而 MVP 的 Model 就像前一段所说，不是一个 Class，而是代表 Business Logic 的 Sub-System。当前端显示平台在做转换时，可以由示意图中看出在 Presenter 这半边的设计是可以保持不变的，也就是说在设计上可以保持最大程度的重用性。以上面二个示意图来说，原本在 App 中是以 MVC 的架构来提供画面的呈现，而移到 Web 平台之后，则可以改采适合 Web 的架构来作为画面呈现的基础，相关的 Business Logic 则不需要更改。
当然以上是针对设计的部份，如果连 Source Code 都要可以重用，则不可能这么直接地就达成目的。以上面的例子来看，如果原本开发的 App 是在 iOS 平台上，我想应该不会有人想要用 Objective-C 来开发一个网站吧！在这样的情况之下所有的 Source Code 势必得重新来过，只是相对地比起其他全新网站的 Case 来说，省下了不少在设计上所需的工作。
不过要让 Source Code 可以重用也不是不可能实现，只是在设计的阶段就必须要做好规划。一开始就要让代表 Business Logic 的 Model 与 Presenter 的互动是以 Remote 的方式进行，如此一来，不论前端的显示平台是什么技术、什么架构，都可以直接重用 Business Logic 的 Source Code。
知易行难，概念上并不复杂，在实作上却是有很多的细节需要考量，未来有机会将另辟篇幅针对更细部的设计做进一步的讨论。更多深入的文章请参阅 http://www.jianshu.com/u/fea63707e07f。
再把焦点拉回到主题上，其实要选择 MVC 或 MVP 并没有人可以告诉你正确的答案。因为每个 Case 都具有一定的独特性，没有方案是万用的，只有最适合的。以上面提到的设计手法来说，在某种程度上是把设计给复杂化了，如果你没有跨平台的需求，又或者你的画面简单到只有一、二个，这样的设计手法就显得叠床架屋、累赘了点。
所以当你在担任设计的工作时，要选择哪一个架构对目前的 Case 来说是最适合的，是你责无旁贷的课题。这是需要经验，也是需要时间去思考的。你的烦恼也是其他正在设计系统的人所烦恼的，而你要做的、能做的也只有从不断地尝试与调整中成长。
网友评论