根据我的理解，画了个图

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

往往一个项目有多个部份，我们可以按功能分成几个activity, 每个activity有自己的view和数据model，因此也有自己的逻辑 presenter,, 如果真正能够按照 M V P模式来组建一个工程，那么整个项目思路将会十分清晰，并且每个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