最近项目不太赶时间，空余的事件研究了一下MVP的架构，在以往的使用MVC模式下的代码耦合度实在是太高了，小项目还无所谓，但是碰到稍微大一点的项目，activity中的代码简直是惨不忍睹，上千行的代码对于MVC来说还算是少的，几千行的代码怎么看，怎么看，看的头疼，维护起来更是头疼的要命，所以为了学习也为了后来的小盆友能清晰的看懂代码，方便的维护代码，索性研究一下MVP模式。以下是自己理解的MVP，如有不对，请包涵。
最近在看MVP的时候也顺带又理解了一下MVC的模式：
MVC模式的模式主要就是：
model（模型），view（视图），cntroller（控制）三个模块之间都会有互动和联系，所以说耦合度会很高，就比如说activity中，既要去刷新试图，还要去处理逻辑代码，还要处理网络请求等等各种问题，使得activity中的代码量很容易就上去了。所以以后自己看代码都有可能忘记这个地方为什么这么写，这么写是为什么。所以还是要去学习啊，时代在进步，自己不进步就完犊子了。
MVP模式的自我理解：
MVP的直观感受就是，接口多，类多。这是我在看MVP架构时的第一感受，当时我在想，这么多接口，这么多类真的容易去维护么，随着稍微深入的研究了一下，才发现这个架构的好处，模块之间的耦合度低，项目构架层级清楚，清晰明了，下面来看看自己写的很白痴的demo：
这张图示我随便的建立的一个架构，瞎写的不过可以清晰的看到三个模块。
model（模型）：用来处理一些网络请求，数据逻辑类的。
view（视图）：我把activity分类到了view一类中，主要就是处理用户界面的数据更新，刷新等操作。
presenter（主持）：这个就类似与把控者了，控制view和model之间的联系。
总的来讲个人理解的MVP就是把以前activity中除了界面刷新以外的逻辑都拿了出来，也就是说，view会响应用的的操作事件，通过接口方式告诉presenter有事件发生，presenter再通过接口来告诉model事件发生所要进行的操作，model执行完一系列的处理通过接口将结果返回给presenter，presenter再将数据返回给view进行界面的刷新，整个过程中view和model是没有交互的，都是通过presenter来完成的。
网友评论