依据我的理解，画了个图

这次又看了下 较复杂点的样例。

往往一个项目有多个部份，我们可以按功能分成几个activity, 每一个activity有自己的view和数据model，因此也有自己的逻辑 presenter,, 假设真正可以依照 M V P模式来组建一个project，那么整个项目思路将会十分清晰，并且每一个MVP 三个方面的工作量都会很少，并且能逻辑清晰地去写代码。

上一篇的解析，逻辑方面应该是正确的，但并不是什么数据，都由一个model来存放，不同的数据应该有不同的model，比方学生跟老师，presenter和view接口也一样，不同的作用和不同的实现就有不同的presenter和view，而且能够实现重用，比方研究生和本科生能够用同一个模板presenter，仅仅需将model的数据改变一下而已，这将会降低反复的工作，体现重用的思想。

这次认为有点乱乱的，不知道要怎样表达，也没再学到很多其它东西了。只是画了个图，以后看到也会更清晰了。。。。以下就借鉴一下别人的总结吧。。。。

在MVP里，Presenter全然把Model和View进行了分离，基本的程序逻辑在Presenter里实现。并且，Presenter与详细的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候能够保持Presenter的不变，即重用！

MVP的长处

　　1、模型与视图全然分离，我们能够改动视图而不影响模型。
　　2、能够更高效地使用模型，由于全部的交互都发生在一个地方 —— Presenter内部。
　　3、我们能够将一个Presener用于多个视图，而不须要改变Presenter的逻辑。这个特性很的实用，由于视图的变化总是比模型的变化频繁。
　　4、假设我们把逻辑放在Presenter中，那么我们就能够脱离用户接口来測试这些逻辑（单元測试）。

　　MVP的缺点

　　因为对视图的渲染放在了Presenter中，所以视图和Persenter的交互会过于频繁。另一点须要明确，假设Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图须要变更，那么Presenter也须要变更了。比方说，原本用来呈现Html的Presenter如今也须要用于呈现PDF了，那么视图非常有可能也须要变更。

http://www.360doc.com/content/12/0405/13/8101845_201083284.shtml