MVP架构。。。。

Model-View-Presenter(MVP)概述
    
MVC模式已经出现了几十年了,在GUI领域已经得到了广泛的应用,由于微软ASP.NET MVC Framework的出现,致使MVC一度成为.NET社区的热名话题。作为MVC的变种MVP模式,也已经出现好几年了,在微软模式与实践小组提供的Web Client Software Factory中,给出了实现MVP模式的应用程序最佳实践,本文将试着对这两种实现比较一二。
MVC(Model-View-Controller,模型-视图-控制器)模式是80年代Smalltalk-80出现的一种软件设计模式,后来得到了广泛的应用,其主要目的在于促进应用中模型,视图,控制器间的关注的清晰分离。MVP(Model-View-Presenter,模型-视图-表示器)模式则是由IBM开发出来的一个针对C++和Java的编程模型,大概出现于2000年,是MVC模式的一个变种,主要用来隔离UI、UI逻辑和业务逻辑、数据。在下面的文字中,如无特别说明,MVC均指ASP.NET MVC Framework。

Model-View-Presenter(MVP)优缺点
    
针对ASP.NET MVP Sample实例,在这个实例中MVP模式采用了Castle框架和底层数据映射NHibernate框架,在开发过程中要注意NHibernate的版本的不同,有的支持sql server 2000,有的支持sql server 2005数据库。IHttpModule接口的实现。其实在使用Castle框架时,IContainerAccessor接口已经封装了IoC模式。还有泛型编程。事务回滚操作。在编程过程中,你可以保留它现有的模式,也可以增加或改变其模式。
    Model-view-presenter旨在应用程序分层和提高测试效率,它的主要目标是将显示逻辑与业务逻辑分离,正如我们设计面向对象程序中创建松散耦合并可重用的对象。
    MVP的另一个目标是提高针对View的测试效率。编写依赖Session, ViewState, AJAX, HTML或web控件和业务实体的单元测试类较为复杂,因此我们将各视图的显示逻辑保留在ASPX/ASCX文件类中,并将业务逻辑从中分离出来放在相应的类中,在MVP中Presenter充当视图和业务逻辑的缓冲层。

MVPMVC的区别
    
MVP——Model-View-Presenter 它是MVC模式的变种。UI是容易变化的,且是多样的,一样的数据会有N种显示方式;业务逻辑也是比较容易变化的。为了使得Application具有较大的弹性,我们期望将UI、逻辑(UI的逻辑和业务逻辑)和数据隔离开来,而MVP是一个很好的选择。
    Presenter代替了Controller,它比Controller担当更多的任务,也更加复杂。Presenter处理事件,执行相应的逻辑,这些逻辑映射到Model的Command以操作Model。那些处理UI如何工作的代码基本上都位于Presenter。Presenter如同一个乐队的指挥家,表现和协调整个Application,它负责创建和协调其它对象。
    Model和View使用Observer模式进行沟通;而Presenter和View则使用Mediator模式进行通信;Presenter操作Model则使用Command模式来进行。基本设计和MVC相同:Model存储数据,View表示Model的表现,Presenter协调两者之间的通信。在 MVP 中 View 接收到事件,然后会将它们传递到 Presenter, 如何具体处理这些事件,将由 Presenter 来完成。

图1:Model-View-Controller

图2:Model-View-Presenter
处理流程方面,在MVC中,用户的请求首先会到达Controller,有Controller从Model获取数据,选择合适的View,把处理结果呈现到View上;在MVP中,用户的请求首先会到达View,View传递请求到特定的Presenter,Presenter从Model获取数据后,再把处理结果通过接口传递到View。
使用MVP后,我们可以提高对Model和Presenter的复用,比如可以对Model和Presenter不做修改,而能提供ASP.NET Web Form和 Windows Form。
在ASP.NET MVC Framework中,采用行内代码进行数据呈现,逻辑集中在Controller中,但是View无法完全交给UI设计人员完成。在MVP模式中,所有的业务逻辑交给Presenter去处理,这样View中代码就变得及其简洁,将可以轻易的把开发人员和UI设计人员分开,如下图所示:

MVP实例讲解
  
下面看一个简单的例子:
  该方式将创建Presenter,传递View和model,调用“InitView”方法的功能交给ASCX用户控件(View)处理。View应用相应的Presenter,Presenter只知道View的接口。ASPX页只用于添加用户控件,因此只需要将用户控件拖拽到页面上可以很容易的重用。

public class Presenter
{
    public Presenter(IView view, IModel model)
     {        
        this.view = view;
        this.model = model;
    }

public void InitView(bool isPostBack)
     {
        if(!isPostBack)
         {
            view.SetProducts(model.GetProducts());
        }
    }
    
    public void SaveProducts(IList<IProduct> products)
     {
        model.SaveProducts(products);
    }
}

//页面或用户控件CS代码
protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    presenter = new Presenter(this,model);
    presenter.InitView(Page.IsPostBack);
}

public void SetProducts(IList<IProduct> products)
{
    //bind products to view
}

//视图接口
public interface IView
{
    void SetProducts(IList<IProduct> products);
}

通过上面的代码就可以了解到MVP的结构是什么样的,可根据这种模式来开发你的项目。当然你也可以从codeplex网站上下载一个Demo,进一步理解。希望这篇文章能对大家有用。

企业级MVP架构的应用
  
在企业级ASP.NET应用中使用MVP 
1、使用用户控件封装Views:这个主题讨论用户控件作为MVP中的View。
2、MVP的事件处理:这个主题讨论连同页面验证传递事件到Presenter,IsPostBack和将消息传递到View。
3、MVP和PageMethods的页面重定向:这个主题讨论使用用户控件作为View,如何使用PageMethods处理页面重定向。
4、MVP的Presentation安全控制:这个主题讨论如何根据基本的安全限制显示/掩藏View中的区段。
5、使用MVP的应用的架构(高级):这是个重点,这个主题展示一个使用Nhibernate作为数据访问层的MVP应用。

Codeplex网站上的那个例子,含概的内容不少,大家可以下载下来分析。

MVP工作感言
 
   这次写这篇文章,主要是解读MVP框架,针对微软MVP的一个例子讲解所涉及到的一些应用模式。最近公司项目采用了MVP架构来开发,对我来说有颇多收获和感慨。对于MVP模式来开发,应当算是新的架构,因为之前只知道微软MVP(Microsoft Most Valuable Professional),并不知道MVP(Model-View-Presenter)。自从来到博客园里不断学习,不断借鉴,丰富了自己的知识。在此要感谢drummery和ξ箫音ξ两位老师的文章,同时也借鉴了UML软件工程组织网站的文章。MVP模式开发项目,我想未来几年将会越来越被许多人使用开发项目。在这里的MVP,我想同样应该实用于开发Windows软件项目。这篇文章写的比较仓促,难免有误之处,同时我也在不断的挖掘MVP的更深层次的应用。在这里这是我个人的理解,希望高人点评指点,若您有其他的理解,可以与我共同探讨。希望大家一起学习,共同进步。

时间: 2024-10-08 08:17:37

MVP架构。。。。的相关文章

mvp架构解析

MVP现在已经是目前最火的架构,很多的框架都是以MVP为基础,甚至于Google自己都出一个MVP的开源架构.https://github.com/googlesamples/android-architecture,里面有好几个项目,我们先谈下todo-mvp这个最基础的MVP架构. 说到MVP,我们不得不谈到最最经典的MVC架构.什么是MVC,概括来说就是数据层,控制层以及显示层的分离.虽然我们可以把所有的代码都写在一个类里,但是作为了一个优秀的程序员你我想一定不会这样做,所以我们想到了解耦

浅谈MVP架构及开发模式

Model-View-Presenter(MVP)概述    MVC模式已经出现了几十年了,在GUI领域已经得到了广泛的应用,由于微软ASP.NET MVC Framework的出现,致使MVC一度成为.NET社区的热名话题.作为MVC的变种MVP模式,也已经出现好几年了,在微软模式与实践小组提供的Web Client Software Factory中,给出了实现MVP模式的应用程序最佳实践,本文将试着对这两种实现比较一二.MVC(Model-View-Controller,模型-视图-控制器

Android开发中的MVP架构(转)

写在前面,本博客来源于公众号文章:http://mp.weixin.qq.com/s?__biz=MzA3MDMyMjkzNg==&mid=402435540&idx=1&sn=1cd10bd9efaac7083575367a8b4af52f&scene=1&srcid=0910ARzPpBvVYPI1NDBZnixa#wechat_redirect 最近越来越多的人开始谈论架构.我周围的同事和工程师也是如此.尽管我还不是特别深入理解MVP和DDD,但是我们的新项目

mvp架构模式

今天是国庆节,祝大家节日快乐,愿祖国越发繁荣昌盛.假期程序员也不能偷懒,更新一些博文吧. 看到封面图片喜欢NBA的人可能很容易就想到了最有价值球员.但是此mvp非彼MVP,此mvp指的是现在Android开发中比较常见的一种软件架构模式.mvp架构模式是Google官方推荐的架构模式,特别是近年来的新项目,mvp+retrofit+rxjava+dragger2配合使用已经在引领程序界的潮流了,在github上可以轻易的搜到一大堆这样的开源项目.前端时间笔者也在公司的一个sdk上进行了尝试,在此

NMock学习系列(二)--- NMock在MVP架构系统的单元测试中的应用

介绍 上篇已经学习了NMock的一些基础概念和代码,同时也想到了可能的两个应用场景,本篇开始学习下第一个应用场景---NMock在MVP架构模式下的应用场景.MVP的架构模式概念比较简单,主要是以接口的形式隔离视图与控制器之间的耦合,具体对于MVP模式的介绍请自行搜索学习.本篇接下来的学习前提是读者了解MVP的架构模式,主要明白视图接口的解耦. 应用场景 基于MVP模式的项目往往业务逻辑的编写和视图的建立是分开进行的,视图只需定义出接口供业务控制器进行依赖调用.所以如果在视图还未具体实现的情况下

Android中的MVP架构

Android应用的MVC架构,Activity往往充当了View和Control双重角色,造成代码耦合性较强.怎样将View和Control解耦呢,可以使用MVP架构(Model.Control.Prestener)将Activity的View和Control彻底分离,不说废话了直接上代码吧! github: https://github.com/Allin1579/Allin-android 以Activity为例,Fragment的原理相同: View:我们将Activity看作一个单纯的

Android中的MVP架构初探

说来惭愧,MVP的架构模式已经在Android领域出现一两年了,但是到今天自己才开始Android领域中的MVP架构征程.闲话不多说,开始吧! 一.架构演变概述 我记得我找第一份工作时,面试官问我"android是否属于MVC架构模式,简述一下".确实,Android的整体设计结构就是MVC的设计模式,在J2EE的开发中,使用的也是MVC模式,MVC模式是一个经典,经历了几十年的考验.Android项目中的MVC架构: View:是应用程序中处理数据显示的部分,对应于layout文件下

用户登录(Material Design + Data-Binding + MVP架构模式)实现

转载请注明出处: http://www.cnblogs.com/cnwutianhao/p/6772759.html MVP架构模式 大家都不陌生,Google 也给出过相应的参考 Sample, 但是有的人会有疑问为啥 GitHub 上面大神写的 MVP架构模式 和 Google 的不太一样. Google MVP架构模式 Sample 地址 https://github.com/googlesamples/android-architecture/tree/todo-mvp/ 下面我们就仿照

Android MVP架构分析

App架构在Android开发者中一直是讨论比较多的一个话题,目前讨论较多的有MVP.MVVM.Clean这三种.google官方对于架构的态度一直是非常开放的,让开发者自主选择组织和架构app的方式,期望能留给开发者更多的灵活性. 由于没有一套权威的架构实现,现在很多App项目中在架构方面都有或多或少的问题.第一种常见问题是没有架构,需求中的一个页面对应项目中的一个activity或一个fragment,所有的界面响应代码.业务逻辑代码.数据请求代码等等都集中在其中.第二种常见的问题是架构实现