辨析三层架构MVC与MVP
MVC架构大家在熟悉不过了，Model,View,Controller.不过在这里我再简单的介绍一下，在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，补课避免的还要包括一些业务逻辑。（在MVC业务逻辑的地方是值得注意的！！）。在MV模型里，更关注的Model的不变，而同时有对个对Model的不同显示，及View.所以在MVC模型里，Model不依赖与View.(这句是废话，MVC分三层就是为了解耦，怎么还会有依赖)。但是呢，View是依赖Model的。不仅如此，还有前面说的有一些业务逻辑在View里实现了。导致更改View也是比较麻烦的，至少哪些业务逻辑是无法重用了(也就是说MVC有一个这样的问题)。
正视因为MVC有上面所讲的问题，那么下面我来讲一下MVP模式,Model,View,Controller。在MVP里，用Presenter完全把Model和View进行了分离，主要的程序逻辑都在Present里实现。而且Presenter与具体的View是没有直接关联的。而是通过定义好的接口进行交互的，从而使得在变更View时候可以保持Presenter的不变，即重用！不仅如此，我们甚可以在Model和View都没有完成时候，就可以通过编写Mock Object（即实现了Model和View的接口，但没有具体的内容的）来测试Presenter的逻辑。
在MVP里，应用程序的逻辑主要在Presenter来实现，其中的View是很薄的一层。View只应该有简单的Set/Get的方法，用户输入和设置界面显示的内容，除此就不应该有更多的内容，绝不容许直接访问Model,这就是与MVC很大的不同之处。
接下来让我再来介绍一下MVP的优点：
1.模型是视图完全分离，我们可以修改视图而不影响模型。
2.可以更高效地使用模型，因为所有的交互都发生在一个地方，Presenter内部。
3.可以将一个Presenter用于多个视图，而不需要改变presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
4.就是便于测试，如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。
再来讲讲MVP的缺点：
由于对视图的渲染放在了Presenter中，所以视图和Persenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。
在最后做一个总结，通过上面的简介，我想大家应该可以了解到MVP,与MVC的不同与相同了，在选择使用MVP或者是MVC的过程中，可以根据，前段业务逻辑，和前台界面的复杂度来灵活的选择使用哪种模式。（还有其余的地方还请诸多前辈在这里指教！）最后谢谢开源中国这个平台，给我提供学习和成长的机会。@红薯
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
