以前的东西-Mvp2
看了回复发现有些人对MVP的理解和我的理解有些差别，写了下面的东西。
主要参考了下面几篇文章
http://codebetter.com/blogs/jeremy.miller/articles/129542.aspx
http://codebetter.com/blogs/jeremy.miller/archive/2006/02/01/137457.aspx
http://www.martinfowler.com/eaaDev/SupervisingPresenter.html
http://www.martinfowler.com/eaaDev/PassiveScreen.html
在asp.net中用MVP的原因：
在软件设计中最重要的一条原则是“分离关注点”，每一段代码有且仅有一个职责，才那能使程序有良好的可维护性。即使在编码的起点，也应该明确一次只解决一个问题，如，我希望只关注业务逻辑而不管数据库结构、html等。
构建可维护的用户界面代码的传统做法是MVC模式。可惜，asp.net为RAD做了优化而没有关注创建可维护性的代码，asp.net模型本身就没有对MVC提供很好的支持，许多asp.net程序把数据访问、html标记、业务逻辑混合在了一起，code－behind模型也没有很好的分离关注点，再加上code－behind很难做单元测试，这些都是要引入MVP的原因。
MVP和MVC问题：
Code－behind的作用？
Code—Behind不能作为MVC的控制器，他只能作为单纯的View，许多维护问题都是由把Code-Behind作为控制器引起的。在MVP中Presenter不能引用System.Web名称空间，是P依赖于V。即使其他的模式也应该尽可能的使Code－behind的只作为界面（View）的辅助，而不包含业务逻辑、控制代码。
MVP中V和MVC中V的区别？
V在MVP中是界面的非常简单的包装（一定要简单到不涉及逻辑问题），MVC中V是指完全被动的。
MVC的类结构
目的是要把尽可能多的功能从asp.net运行时分离出来，也就是说把Page的职责分解到几个类中：
View：显示数据、把用户输入和触发的事件推迟到Presenter。
通常需要一个接口（Interface），代表所有的View，后台代码把此接口当作界面，而不需要Page、system.web中的类，此接口封装了与asp runtime的交互。
界面和后台的逻辑都通过此接口传递信息。
Presenter：协调View和后台服务、业务逻辑，负责页面逻辑。P只能依赖于IView、Modle（最好用Facade模式，提供一个中间层，隔离Model）。P的功能不能太多，MVP中P负责的一般比MVC的C多，但是从功能上细分P到几个类有时是必要的，如验证、分页、排序等，使P不至于便的很大，并且有内聚性。
V的要点：
1、V必须依赖于接口Iview
2、 IView，尽量减少简单的POCO似的属性，而要把这些封装成类或者暴露DTO，甚至MOdle，如
public interface IWorkItemView
{
// Packs the user input into a new WorkItem class
WorkItem WorkItem{get;}
// Sets the values in the dropdown list for the WorkItem assigned to user
string[] AssignmentList {set;}
// Sets the values in the dropdown list for the WorkItem categories
string[] CategoryList {set;}
}
public interface IWorkItemView
{
string AssignedTo {get; set;}
string Category {get; set;}
string Description {get; set;}
string Priority {get; set;}
string Comments {get; set;}
/* More properties */
}
P的要点：
1、View可以有多个Presenter，如一个负责低层次的View和Model映射和验证。另一个Presenter负责业务逻辑和后台服务
后面的找不到了
