工作几年，发现代码写的越久，写代码前考虑的东西越多，越小心也越慢了。如果之前总是20%编码时间需要80%时间来debug和维护，那现在当然希望debug所占的时间越少越好，在编码之前更多的构思和设计，尽可能规避可能出现的问题。
不知道从什么时候开始，项目进度总是在拖着我们往前疯狂地写需求，打补丁，当脏代码越来越多，结构越来越臃肿，我们开始想起来一个叫架构的东西。然后又开始计划重构代码，甚至重新设计框架，可惜一堆接一堆的新bug等着去解，重构计划一拖再拖，似乎这才是该做的事情，慢慢忘记了软件里那些真正绚丽的东西。
近段时间得益于开始从事了更多系统和算法层面的工作，有了更多的时间去思考，写代码不用再那么紧急而匆忙，我开始重新学习和应用软件架构的思想到我自己的工作中，不放过每一次可以做架构的机会。
-------------------------------------------
以上为架构之路专栏的开篇废话，下面简单说说最近用到的一个框架模式-MVP，用于光感项目中的PC端离线工具框架，这是我第二次用它。
--------------------------------------------
如果说设计模式是代码优化的小技巧，那框架模式就是软件设计里的大智慧。设计模式就是面试里喜欢考你的单例、工厂、观察者，诸如此类指导我们在coding阶段能直接提升代码逻辑感，层次感甚至性能的东西，而框架模式往往是在软件架构阶段就会被应用的东西。我们经常会见到很多似曾相识的架构，那是因为这些经典思想很多时候可以通用，比如分层、主从、管道，比如代理、监听，当这些架构思想凝结成一种可以直接借鉴的模式，那么框架模式就诞生了。大家最熟悉听过最多的应该就是MVC，而MVP基于它改进，那就从它开始把。
MVC（Model-View-Controller），把业务逻辑抽离到 Controller 中，让 View 层专注于显示 UI。
MVC的图示非常简单：
当用户事件发出的时候，view层会发送指令到controller层，接着controller去通知model层更新数据，model层更新完数据以后直接显示在view层上，这就是MVC的工作原理。
做android开发的同学，看这个例子非常容易理解：对于原生的Android项目，layout.xml里面的xml文件就对应于MVC的view层，里面都是一些view的布局代码，而各种java bean，还有一些类似repository类就对应于model层，至于controller层就是各种activity。
看起来MVC想让展示层和业务逻辑解偶，各司其职。然后view和model还是可以直接访问，耦合性还是挺高，我们很多时候想完全隔离数据层和显示层，让业务逻辑作为中介，这种结构会更加清晰，解偶的更彻底，这就是MVP。
（1）Presenter ：Presenter主要作为沟通View与Model的桥梁，它从Model层检索数据后，返回给View层，使得View与Model之间没有耦合，也将业务逻辑从View角色上抽离出来。
（2）View ：View通常需要实现一个逻辑接口，将View上的操作转交给Presenter进行实现，最后，Presenter 调用View逻辑接口将结果返回给View元素。
（3）Model ：Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据，Model就像一个数据仓库，是业务数据源的通道。可以是本地数据库的封装，也可以是对网络数据的获取者和管理者。
一图胜千言：
MVC和MVP最早用于web框架，现如今用于各种编程语言各类应用软件的体系架构，作为一种通用的框架模式，如果工作中有类似需求场景：解偶展示层和数据层，抽离业务逻辑层作为中间控制层。那么这个框架就是可以借鉴的。
以我工作中需求为例：我将要开发的PC离线工具应该整合进一个框架，目前所需的整机流程回放和对齐，误差性能分析，时间性能分析这些功能都有共同的数据层和结果展示层，且我不希望将业务逻辑直接写到两者之中，便于后续的维护和迭代。于是，我借鉴MVP的思想，做了如下的框架设计，该工具使用python开发，xmind脑图主要展示模块分层以及核心类。（第一张总图不清，后三张分别为M/V/C三层的放大展示）
同MVP原理，view为很薄的一层，且view和model完全隔离，业务方案的变动不会影响两者的实现，只需适配AlsXXStarter中的业务逻辑部分。
为节省时间，画了一个简化的UML类图，省略了类中变量和方法，仅展示类之间的关系。三层结构分别对应MVP三层：
到此，MVP从解释到应用都有了一个大概，最好的借鉴是汲取思想而又不拘泥于模式，改进与否都是服务于你自己的需求，不是吗？