zoukankan      html  css  js  c++  java
  • MVP 总结

    最近一直在看MVP的东西,现在打算来总结一下,以便后边回顾学习

    http://msdn.microsoft.com/zh-cn/magazine/ff955232.aspx

    MVP 的创建者将模型(在视图中处理的数据)与视图/控制器对巧妙地分开。 他们还将控制器重命名为表示器,以强化一种概念,即在该模式中,控制器的角色就是用户与应用程序之间的调节器的角色。 表示器是向用户“呈现”UI 并接受用户所发出命令的组件。 表示器包含大多数表示逻辑,知道如何处理视图和系统的其余部分,包括后端服务和数据层。

    MVP 中的一项重要创新是,视图的详细信息抽象为接口(或基类)。 表示器与视图的抽象层交互,使表示器自身成为一个可重用性和可测试性均很高的类。 这样可实现两种有意思的方案。

    首先,表示逻辑独立于将要使用的 UI 技术。 因此,可在 Windows 和 Web 表示层中重用同一控制器。 最后,针对某一接口为表示器编码,该表示器可以与公开该接口的任何对象进行交互,而无论该对象是 Windows 窗体对象、ASP.NET 页面对象还是 WPF 窗口对象。

    其次,同一表示器可以处理同一应用程序的不同视图。 这是关于软件即服务 (SaaS) 方案的一个重要成就,在这些方案中,应用程序托管在 Web 服务器上,并作为服务提供给每一个要求使用自定义 UI 的客户。

    毫无疑问,这两项优点都不一定适用于所有情况。 这些优点是否会给您带来益处,很大程度上取决于您期望在 Windows 和 Web 前端中使用的应用程序和导航逻辑。 但是,当逻辑相同时,您可以通过 MVP 模型进行重用。

    mvp的一个例子以及讲解,测试驱动开发的好例子

    http://www.microsoft.com/china/msdn/library/architecture/architecture/architecturetopic/MVP.mspx?mfr=true

    http://www.cnblogs.com/therock/articles/2450923.html

    关于mvp很好的讲解

    http://www.cnblogs.com/artech/archive/2010/03/25/1696205.html

    http://www.cnblogs.com/artech/archive/2010/04/12/1710681.html

    CAB的14条编写符合MVP规范的规则:

    1、所有的View(包括View的接口)的名称应该以View作为后缀,比如TaskView/ITaskView;

    2、所有的Presenter名称应该以Presenter作为后缀,比如TaskViewPresenter;

    3、Presenter完成Use Case处理逻辑,对GUI控件的处理应该在View中实现;

    4、View调用Presenter的方法应该像触发事件异常,通过调用OnXxx方法的方式来实现;

    5、应该尽可能地限制View对Presenter的调用,并且调用的方式限于按照“事件”的形式,比如_presenter.OnViewReady();

    6、View不允许通过Presenter直接调用Model和Service,并且Presenter的方法应该是不具有返回值的;

    7、Presenter必须通过View接口的方式调用View

    8、除了对View接口成员的实现外,View中的其他方法不应该是public的;

    9、除了CAB ModuleController 对View的加载和限制外,View只能被Presenter调用;

    10、View接口方法应该基于Use Case的逻辑起一个有意义的名称,比如SetDataSource这样的方法名称是不合法的;

    11、View接口的成员应该仅限于方法,不应该包含属性;

    12、所有的数据应用保持在Model中

    13、定义在View接口的方法不应该包含对GUI空间名称的引用(比如AddExplorerBarGroup),因为这会使Presenter知道View太多关于实现方面的细节;

    14、尽量让View的方法名称反映Use Case的业务逻辑,这样可以使你的代码具有自表述性并更加易于理解。

    View单纯地将用户的交互请求汇报给Presenter;Presenter接收到请求之后,整合相应的资源、执行相应的处理逻辑对处理流程的某一个步骤,如果设置到业务逻辑和数据模型,则调用Model,如果涉及到对GUI控件的操作,还会调用View。View将交互请求递交给Presenter之后,不需要考虑后续需要做什么,因为Presenter会在适当的时候命令View该如何做。

    UI交互逻辑的处理流程定义在Presenter中,但是具体的实现并不是完全在Presenter中

    杜绝开发人员将程序写成基于Proxy的MVP,在我看来,唯一的办法就是尽量弱化(不可能剔除)View对Presenter的依赖。实际上,对于MVP来说,View仅仅向Presenter递交用户交互请求,仅此而已

     

  • 相关阅读:
    搞明白这八个问题,Linux系统就好学多了
    Fedora 25 Alpha版本今天发布啦
    Linux新手应掌握的10个基本命令
    PC-BSD 换名 TrueOS
    JPA+Springboot实现分页效果
    陈亮
    押尾光太郎
    岸部真明
    面试必备-网络的七层协议
    JavaScript中的快速排序
  • 原文地址:https://www.cnblogs.com/RealAlex/p/2749904.html
Copyright © 2011-2022 走看看