这篇文章是我近期对MVC和MVP的一些思考，在使用MVC/MVP模式的过程中曾经走过一些弯路。呵呵，现在虽然改正了某些弯路，但不保证改正了所有的弯路（例如对渲染的理解），所以请阅读这篇文章的朋友不吝发挥你们的质疑。
写这篇文章也是想知道自己还有什么地方是错的，我的最终方案是否可行？
有交流才会有进步。你有一个苹果，我有一个苹果，我们交换后仍各有一个苹果，你有一个思想，我有一个思想，我们交换后......会有N个思想 :p
1. MVC的理解误区
以下是我以前对MVC模式的理解误区：
1. 认为Model是指失血模型的实体类（Entity），是作为View和Controller之间的传输数据。
2. 把业务逻辑全部放在Controller端，认为Controller是用来写UI的业务逻辑的。
这两个误区本质上都是对Model的作用不明导致的。
Model在MVC架构中起的作用非常重要，它才是UI业务逻辑真正的实现层。所以Model的实际上是Business Model（业务模型）。
而 Controller仅仅起一个“桥梁”作用，它负责把View的请求转发给Model，再负责把Model处理结束的消息通知View。 Controller就是一个消息分发器。Controller是用来解耦View和Model的，具体一点说，就是为了让UI与逻辑分离（界面与代码分离）。
2. MVC与VCP的区别
MVC的View直接与Model打交道，Controller只转发请求（View的请求）和通知（Model处理完之后的通知），不传递数据（业务结果），而是由View直接向Model拿数据。
MVP的View不与Model直接联系，所有的请求、结果通知、数据传递都是通过Controller转发，View和Model彼此不知道对方的存在。
3. MVC与MVP的相同点
无论是MVC还是MVP，View和Controller都是紧密联系的，在WinForm模式下更显得突出，View和Controller直接绑定在一起了（在一个类里面）。
MVC/MVP都是通过“通知”机制（观察者模式，在C#中使用事件）来解决View和Controller的交互。
4. MVP框架的设计
在MVP框架里，用Presenter代替MVC的Controller，而且View不再与Model交互。
4.1. Presenter
Presenter的作用比Controller大得多，Controller只是一个纯粹的消息分发器，而Presenter还负责传递Model的处理结果给View，并指导View的渲染。
注意，渲染我理解为UI的展现方式。
4.2. Presenter与Model
Presenter与Model使用接口隔离，Presenter直接调用Model的接口方法（比如IUserModel的FetchUserList()、SaveUser()等）。
4.3. Presenter与View
View与Presenter的交互使用观察者模式，有两种方式实现：
1. View主动使用Presenter。
View主动构造Presenter，并在内部调用Presenter的方法。即先有View再有Presenter。这种情况下，View明确知道自己要使用哪些Presenter。
2. Presenter主动使用View。
Presneter主动创建View，View里面定义有一堆的事件，Presenter注册这些事件。这种情况下，View不知道自己会被哪些Presenter使用。
第二种方式比第一种方式耦合性低，但View里要写一堆的事件，Presenter类里要捕获一堆的事件，感觉写起来很烦琐，代码不雅观。
5. Controller/Presenter的意义
以下Controller/Presenter简称为C/P。
C/P存在的意义是为了解耦View和Model。如果C/P不存在的话，View就直接访问Model，而View的变化是频繁的，不同的系统，View的展现方式不一样，让Model去控制View的渲染，会降低Model的重用性。如果Model不管View的渲染，由View自己渲染，那么就是 WinForm的解决方式，即View和C/P经绑定（合并为一个类）。
6. 为什么要用MVC/MVP模式？
老实说，到目前为止，我依然看不出WinForm把Model分离之后，与标准的MVC/MVP有什麽差距。在WinForm分离Model之后，两者的交互可以用接口隔离，也可以用观察者模式让Form与Model一对多。再用IoC替代View直接构造Model的实例，那么WinForm代表的View+C/P（Form）已经与Model完全解耦了，View+C/P层连Model层都不需要引用（但要引用IModel层）。
这里关键是使用IoC技术，否则WinForm确实会导致View与Model直接耦合，更换Model，或者改变Model的接口会导致View要修改。注意，我们分离出来的 Model，并不完全是为了使UI与代码分离，我们更注重Model的重用性，力求一个Model被多个View享用，甚至是不同系统的View享用。这就要求我们改动View的渲染时不用改动Model，同样地，我们改动Model的内部逻辑时，也不影响View的渲染。
嗯，或许还有一点：View通过Controller/ Presenter交互，使得系以统可以有一个共同的“入口”，系统可以在入口处做拦截，利于日志和权限的处理。但我们可以用AOP技术替代C/P的入口。
7. 新方案
由此看来，IoC+AOP可以完全替代C/P，而且框架上更“干净”，开发人员写起来更自由。
一些零碎的想法，有什么错误的地方请大家多多指教，谢谢。