加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

OFBizChina: 理解MVC模式

发布时间:2020-12-15 22:32:32 所属栏目:百科 来源:网络整理
导读:http://www.cnblogs.com/sunsonbaby/archive/2004/11/29/70707.html 作者: OFBiz中国研究中心,alleysh@ofbizchina.com 最后更新日期: 2003年6月21日 内容 需要考虑的问题 MVC理论描述 系统设计 OFBiz中MVC模式体现 需要考虑的问题 当涉及大量商业逻辑项目的

http://www.cnblogs.com/sunsonbaby/archive/2004/11/29/70707.html

作者: OFBiz中国研究中心,alleysh@ofbizchina.com
最后更新日期: 2003年6月21日

内容

  • 需要考虑的问题
  • MVC理论描述
  • 系统设计
  • OFBiz中MVC模式体现

需要考虑的问题


当涉及大量商业逻辑项目的时候,我们需要考虑什么?如何分离用户界面和后台操作?如何避免将商业逻辑混淆于一般的流程控制中?作为企业信息系统, 就需要考虑很多类似的问题。

源源不断的客户新需求,要进行功能修改和扩充,但是因为程序的高耦合,改动将变得非常困难,导致项目成本何风险增加。 而且,往往维护人员与开发人员不是同一个人, 即使有详尽的文档,也很难理清程序里纵横交错的联系。 所以贯彻Model-View-Controller(MVC)模式的设计, 在设计阶段首先杜绝此类问题,是一个非常好的方法。


MVC理论描述


所谓MVC模式,指的是一种划分系统功能的方法,它将一个系统划分为三个部分:

  • 模型(Model):封装的是数据源和所有基于对这些数据的操作。在一个组件中,Model往往表示组件的状态和操作状态的方法。

  • 视图(View):封装的是对数据源Model的一种显示。一个模型可以由多个视图,而一个视图理论上也可以同不同的模型关联起来。

  • 控制器(Control):封装的是外界作用于模型的操作。通常,这些操作会转发到模型上,并调用模型中相应的一个或者多个方法。一般Controller在Model和View之间起到了沟通的作用,处理用户在View上的输入,并转发给Model。这样Model和View两者之间可以做到松散耦合,甚至可以彼此不知道对方,而由Controller连接起这两个部分。

  • 模型,即相关的数据,它是对象的内在属性;视图是模型的外在表现形式,一个模型可以对应一个或者多个视图,视图还具有与外界交互的功能; 控制器是模型与视图的联系纽带,控制器提取通过视图传输进来的外部信息转化成相应事件,然后由对应的控制器对模型进行更新; 相应的,模型的更新与修改将通过控制器通知视图,保持视图与模型的一致性。 下图(图1.1)描述了这三者之间的关系:


系统设计


系统属于浏览器/服务器模型(Browser/Server)。一般的,客户通过浏览器发送HTTP请求给服务器端Web 服务器,Web 服务器接收该请求并且进行相应处理,然后将处理后的结果返回到客户的浏览器中。在客户端,浏览器中呈现的正是该系统的视图部分。视图的作用就是提供给客户一个可视化的界面,并且允许客户输入一些数据来与服务器端程序交互。

对客户来说,他只能看到视图,而模型和控制器对他则是透明的。在这里Web 服务器仅仅起到提供HTTP服务的作用。Web 服务器将客户提交的HTTP 请求交给后方的Jsp、Servlet引擎,并且进一步交给其中的控制器来处理。控制器按照从xml配置文件中提取的请求映射表将该请求映射到相应的处理器(Handler);处理器对模型进行更新、修改等操作,处理完后返回结果给控制器;控制器根据结果通知视图做相应变化,并且选择相应视图返回给客户。下图(图1。2)说明了这一协作过程。


OFBiz中MVC模式体现


OFBIZ的Web应用框架严格遵循MVC模式。 OFBizMVC中Model有它的封装业务逻辑的事件和服务承担. Control有controller承担, View有传统的jsp,和FreeMarker,JPublish,Beanshell承担。 这里我主要说明 Control (Model,View将在相应技术的模块阐述). 在OFBiz框架中,Controller是一组管理web表示层对象,其目的是将业务逻辑和表示层完全地分离开来。

  • 过滤器(Context Security Filter)
  • Control Servlet 控制程序流程
  • Handler对请求的处理过程

过滤器(Context Security Filter)

Servlet API 2.3中最重大的改变是增加了filters,filters能够传递request或者修改response。 Filters并不是servlets;它们不能产生response。你可以把过滤器看作是还没有到达servlet的request的预处理器,或从servlet发出的response的后处理器。一句话,filter代表了原先的"servlet chaining"概念,且比"servlet chaining"更成熟。
filter能够:

  • 在servlet被调用之前截取servlet
  • 在servlet被调用之前查看request
  • 提供一个自定义的封装原有request的request对象,修改request头和request内容
  • 提供一个自定义的封装原有response的response对象,修改response头和response内

Context Security Filter (CSF) 在 /WEB-INF/web.xml 定义,用来限制访问 web应用程序的文件. 具体参看下面的例子.
filter配置如下:

<filter> 
  <filter-name>ContextSecurityFilter</filter-name>
  <display-name>ContextSecurityFilter</display-name> 
  <filter-class>org.ofbiz.content.webapp.control.ContextSecurityFilter</filter-class>    
  <init-param> 
    <param-name>allowedPaths</param-name> 
    <param-value>/control:/index.html:/index.jsp:/default.html:/default.jsp:/images</param-value>    
  </init-param> 
  <init-param> 
    <param-name>errorCode</param-name>    
    <param-value>403</param-value> 
  </init-param> 
</filter>    
<filter-mapping> 
  <filter-name>ContextSecurityFilter</filter-name>    
  <url-pattern>/*</url-pattern> 
</filter-mapping> 
      

Control Servlet 控制程序流程

Control Servlet 是所有请求过程的核心. 当收到一个请求时,servlet 首先设置系统环境信息,初始化request,session,实体代表(采用了"业务代表"的 设计模式,我们将在关于实体引擎文章中介绍),Service Dispatcher,and Security Handler 存放在ServletContext. 随后control server 将request交给了 Request Handler 处理. Request Handler处理完成后,返回给control servlet,整个请求过程就结束了。


Handler对请求的处理过程

Request Handler 利用RequestManager帮助类收集在定义在/WEB-INF/controller.xml 中的请求映射(mapping) . 映射建立了 URI和VIEW的对应关系。 URI又和Event紧密相连,Events用来处理可以直接通过实体引擎,或者调用服务的方式处理业务逻辑。

当Request Handler 收到一个请求后,首先察看请求映射 (mapping),如果没有发现对应的当前请求定义或者请求映射,返回错误。 如果察看成功,调用Security Handler检查当前的请求是否需要验证和使用这个 请求的用户身份验证。如果当前的用户没有验证,Request Handler直接将请求转向到登录页面。 成功验证之后, Request Handler寻找当前请求的事件Event。并将请求转交给EventHandler. 当事件处理完成之后, 又将reuqest移交给 ViewHandler. 如果view类型是url,直接重定向到 url,否则根据不同的 view类型。调用不同的 view handler 处理(如:JPublishViewHandler,RegionViewHandler,FreeMarkerViewHandler)。

请求映射定义实例:

<request-map uri="checkLogin" edit="false">
    <description>Verify a user is logged in.</description>
    <security https="false" auth="false"/>
    <event type="java" path="org.ofbiz.commonapp.security.login.LoginEvents" invoke="checkLogin" />
    <response name="success" type="view" value="name" />
    <response name="error" type="view" value="login" />
  </request-map>
       

如上所示, 事件返回" success" 调用view: main 。如果这里的 type="request",返回成功以后,自动调用另外的请求。 这就是所谓的"请求嵌套"。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读