Mvp

引进 MVP 更容易进行分层测试，比如依赖注入 b/s结构，但你真正要实现多界面，换肤，或者经常要升级改动时，MVP模式确实可以带来很多的方便，特别是大型项目，分工就更加明确了....请lz看vs2008的MVC框架，现在还没有正式版发布的 在ASP.NET WebForm MVC框架出来之前，.Net方面的Web应用程序的开发主要是基于Web窗体的框架，基于这种框架的优点主要有： 事件模型。 Web 窗体支持与 Windows 应用程序类似的事件驱动编程模式。 许多事件可用，数百个服务器控件对它们提供支持。 状态管理。 Web 窗体通过使用视图状态和基于服务器的控件降低了状态管理的复杂性。 基于页面的体系结构。 Web 窗体提供了一种体系结构，此体系结构将含声明性标记的页面（.aspx 文件）与添加功能的代码隐藏文件相结合。 通过使用此结构，可以轻松地创建能够执行常规任务（如对用户操作作出响应以及呈现服务器代码中的标记）的页面。 大批控件。 ASP.NET 社区提供了数百个可减少开发时间的服务器控件和组件。 也正因为这些优点，能够很快的使用Web窗体框架开发应用程序。但基于Web窗体框架开发的应用程序是很难进行测试的，而且Web窗体框架中业务逻辑和页面显示逻辑混杂在一起，随着业务需求增加，应用程序变得愈加复杂，使得应用程序的质量难以保证，程序的维护也变得更加艰难。 现在，虽然可以使用ASP.NET WebForm MVC框架进行开发，通过完善的单元测试来提高应用程序的质量，但仔细考虑会发现几个问题： 已有的Web窗体开发的技术积累基本无法重用 团队的新框架学习的成本可能会比较高 新进入公司的员工培训难度也可能提高 因此我们更希望的是通过其他方式来达到目标，于是发现可能使用MVP（Model-View-Presenter，模型-视图-表示器）模式的Web窗体框架能够在比较低的成本花费情况下提高我们的应用程序质量。 所谓MVP（Model-View-Presenter，模型-视图-表示器）模式，是由IBM提出的一个针对C++和Java的编程模型，是MVC（Model-View-Controller,模型-视图-控制）的变种，主要用来隔离UI、UI逻辑和业务逻辑、数据。 首先看一下MVP模式的框架图： 从上面的框架图中可以看到MVP模式的三层结构： View（视图）：显示应用程序的用户界面，根据用户操作激发相应的Presenter业务处理事件，并呈现处理后的视图状态 Presenter（表示器）：响应View激发的处理事件，进行业务逻辑处理并将数据提交给Model层，最后根据操作结果更新视图状态 Model（业务模型）：业务实体的持久化 由此可以看出通过这样的层次结构将UI的逻辑和业务实体的逻辑进行了清晰的分离，整体来说MVP模式主要有以下优点： 职责的分离。将职责分离到不同的部分后，使得复杂的业务能够简单的实现、使得应用程序的维护也变得更轻松，同时也能提高代码的重用性。 提高可测试性。以前的页面由于将不相关的部分（视图、业务模型、表示器）包含在一起，导致很难进行测试，但是将这些部分分离开来之后就使得测试变得容易。 多视图。将视图和业务模型分离之后，视图不会直接依赖于业务模型，那样我们能同时将相同的数据通过多个不同的视图进行展现。 适应变化。通常来说界面的变化往往比业务逻辑的变化更加频繁，不同的用户可能喜欢不同的展现风格、或者使用不同的设备进行展现，当业务模型不再依赖视图之后，添加新类型的展现视图变得更加容易，而且不会影响到业务模型。 而且MVP模式只是一种编程模型，在.NET平台中可以用在ASP.NET Web Form应用程序、Windows Forms应用程序等，现在也有一些实现了MVP模式的框架提供使用，主要有Claymore、MVC# Framework、NMVP Framework、ASP.NET Web Forms Model-View-Presenter (MVP)等。 通过上面对MVP模式的介绍，的确可能有些情况下在Web窗体中使用MVP模式会比MVC模式更适合，但哪个框架会比较适用还是需要通过实践来验证，接下来会继续介绍MVP的使用以及在使用过程中的一些体会。