MVC/Model 2模式、MVP模式和MVVM模式

前言

时间过得很快，距离2019铁人挑战赛将近一年了，在这一年间除了持续进行android程式设计的开发之外，也接触了不少新东西！例如：重构、实作模式、测试驱动开发、kotlin、资料科学概念、python、机器学习等等，在眼界跟技术方面都有某部分的成长。

在去年的铁人挑战赛 MVC模式、 MVP模式、 MVVM模式，这三种程式架构，是我一直想藉机希望有更深入了解的，不过因为工作生活等等各种繁杂事物(?)，一直拖欠到今天，而且现在也在犹豫要不要参加今年的铁人赛，所以先写一篇小文章练练文感哈。

定义

首先先介绍一下MVC模式，我们先看一下wiki上的定义

MVC模式最早由Trygve Reenskaug在1978年提出[1]，是全录帕罗奥多研究中心（Xerox PARC）在20世纪80年代为程式语言Smalltalk发明的一种软体架构。MVC模式的目的是实现一种动态的程式设计，使后续对程式的修改和扩充简化，并且使程式某一部分的重複利用成为可能。除此之外，此模式透过对複杂度的简化，使程式结构更加直觉。软体系统透过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。

— wikipedia MVC

Wiki上的定义算是蛮清楚的，但是如果运用在实际开发上呢？因为我对Android开发比较熟悉，用Android开发做为例子说明。

因为在Android开发中创立专案资料夹设计的关係，基本上算是Android开发中预设的模式，在使用上目前是最为直观和容易理解的，把程式码切分为Model、View、Controller这三种角色。

将MVC架构，经由图示化呈现的话程式会像下面这样 —

图示看起来算是蛮清楚容易使用的，实际用起来也是没有什么大问题，很适合在小专案或是短期的开发上使用，但是如果开发专案週期一长，程式码堆积起来的话就会发现致命缺点。

MVC模式使用在Android开发上，在程式经过一定的开发週期后，由于Controller负责了整个程式的逻辑部分，不可避面的会发生Controller变得非常肥大的状况出现，也因为这样使得程式码的修改和维护变的相对困难很多。

程式码肥大这种状况也出现在其他语言和专案开发上，例如使用 Java进行网页开发的 Servlet/JSP，和使用 Python和 django框架的网页开发，这几种程式开发的共通点是 View和 Controller中有高度的耦合，所以在专案开发最后，程式码发生难以修改和测试验证的状况。

另外因为架构设计已经有些历史，这类MVC架构有个不怎么出名的名称叫做Model 2，有兴趣的同学可以读读这篇文章分享。

MVP模式

在查询各种资料之后，我认为MVP模式是MVC模式的一种变种，和MVC模式相当相似，定义也相对比较模糊，所以我认为MVP模式可以视为是广义的MVC模式来理解，将Controller的任务做或是变换，使得专案架构有一致性。

MVVM模式

MVVM模式是比较有特色的模式并且相当实用的，将View和Model绑定为ViewModel，使得资料的变换和UI的变换同时发生，并且减少所需要撰写的程式码数量。

将MVVM架构，经由图示化呈现的话程式会像下面这样 —

可以看到图示化之后和MVC模式非常相识，而原本的Controller位置，换为ViewModel呈现，并且实现与Model的资料绑定，藉此使得专案更为乾净，不用写一大堆主动更新View的程式码。

结论

时间演进之后，出现了很多不同的专案架构设计，并没有最好的架构，而这些设计最为根本的还是为了实现客户需求和完成专案而存在的，在不同的需求和专案中，使用最为方便和快速实现功能的架构，或是更为严谨的架构，都有其优缺点存在，理想的状态是根据不同的状况而使用不同的架构。

举个例子来说，在开发只有两三页的测试用小专案时，就不用太纠结一定要用哪一种模式，使用最熟悉并且好上手的架构进行开发就可以了，当然如果是专门用来练习架构的专案例外啰～

关于架构每个人的看法都会有点不一样，在这篇文章提供一下自己的看法，抛砖引玉，希望对大家能有一些帮助，如果有什么意见也欢迎提出～