看到这个题目，我估计绝大部分朋友会第一时间想到 model-view-controller （ MVC ）模式。的确这个是在 GUI 设计领域里应用最为广泛的模式了， 3 个模块相互之间交互，大家耳熟能详，我就不多费笔墨了，不了解的朋友请察看 MVC简介
在进行 view 和逻辑分离的工作中，大家知道最多的是 MVC, Model-View-Presenter (MVP) 知道的并不多
MVC
可以参看 MVC简介 ， Castle.MVC 框架介绍
MVP
由 Martin Fowler 发现并进行研究， Martin Flowler 的文章 Model View Presenter 进行详细的介绍。 从根本上来说，她只是个 MVC 的变种。在 MVC 中 view 直接处理相关的 GUI event ，比方说，键盘鼠标事件， checkBox 被选中，按钮被按等等。而在 MVP 中 view 接收到事件，然后会将它们传递到 Presenter, 如何具体处理这些事件，将由 Presenter 来完成。从 class diagram 上来看，就是 Presenter 有 View 和 Model 的引用， Presenter 负责来管理其他两个模块。跟据两者不同来看， MVC 比较适合用来开发 components, 而 MVP 比较适合进行 applications 的开发 , 因为使用 MVP 导致绝大部分逻辑代码集中在 Presenter, 而 view 变得非常简单 , 适当采用良好的编码风格，可以让毫无经验的编码人员稍加培训立刻上岗，大大加速开发 view 的速度， Asp.net 2.0 的 Webform 模型很容易的使用 MVP 模式。
这里有一篇 CAB 与 MVP 模式
下面是一篇文章，来自 http://www.darronschall.com/weblog/archives/000113.cfm
附:
MVC vs. MVP
By now you should've heard of the Model-View-Controller design pattern. If you've read OOP with ActionScript by Branden and Sam then you're also somewhat familiar with the Model-View-Presenter design pattern. So what's the difference?
MVC came first. With the MVC pattern it's possible to separate your presentation information from your behind the scenes business logic. Think along the lines of XHTML/CSS and separating your content from your presentation. A brilliant concept that works quite well, but is not without it's faults.
In MVC, the model stores the data, the view is a representation of that data, and the controller allows the user to change the data. When the data is changed, all views are notified of the change and they can update themselves as necessary (think EventDispatcher).
MVP is a derivative of MVC, mostly aimed at addressing the "Application Model" portion of MVC and focusing around the observer implementation in the MVC triad. Instead of a Controller, we now have a Presenter, but the basic idea remains the same - the model stores the data, the view is a representation of that data (not necessarily graphical), and the presenter coordinates the application.
In MVP the Presenter gets some extra power. It's purpose is to interpret events and perform any sort of logic necessary to map them to the proper commands to manipulate the model in the intended fashion. Most of the code dealing with how the user interface works is coded into the Presenter, making it much like the "Application Model" in the MVC approach. The Presenter is then directly linked to the View so the two can function together "mo' betta".
Basically, in MVP there is no Application Model middle-man since the Presenter assumes this functionality. Additionally, the View in MVP is responsible for handling the UI events (like mouseDown, keyDown, etc), which used to be the Controllers job, and the Model becomes strictly a Domain Model.
Clear as mud, right?
If you're interested in this topic there's quite a bit of useful information out there, but you'll need to take the time to digest it. Check out the following links: (most of these are Smalltalk based, but should still be understandable)
· Model View Controller History
· Model-View-Controller framework
· Model View Controller
· (ootips) - Model-View-Contoller
· Model View Presenter
· Model-View-Presenter framework
· Pattern: Model-View-Presenter
· MVP: Model-View-Presenter (Java paper)
· Twisting the Triad
Above all, remember that MVC and MVP are just patterns. They're more or less a set of guidelines to follow when building applications. In the end, the developer can implement the application however they see fit.
http://www.codeproject.com/dotnet/tdd_in_dotnet.asp