mvc架构模式概念

MVC模式是"Model-View-Controller"的缩写,中文翻译为"模式-视图-控制器"。MVC应用程序老是由这三个部分组成。Event(事件)致使Controller改变Model或View,或者同时改变二者。只要Controller改变了Models的数据或者属性,全部依赖的View都会自动更新。相似的,只要Controller改变了View,View会从潜在的Model中获取数据来刷新本身。MVC模式最先是smalltalk语言研究团提出的,应用于用户交互应用程序中。smalltalk语言和java语言有不少类似性,都是面向对象语言,很天然的SUN在petstore(宠物店)事例应用程序中就推荐MVC模式做为开发Web应用的架构模式。MVC模式是一种架构模式,其实须要其余模式协做完成。在J2EE模式目录中,一般采用service to worker模式实现,而service to worker模式可由集中控制器模式,派遣器模式和Page Helper模式组成。而Struts只实现了MVC的View和Controller两个部分,Model部分须要开发者本身来实现,Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。 

MVC模式是一个复杂的架构模式,其实现也显得很是复杂。可是,咱们已经终结出了不少可靠的设计模式,多种设计模式结合在一块儿,使MVC模式的实现变得相对简单易行。Views能够看做一棵树,显然能够用Composite Pattern来实现。Views和Models之间的关系能够用Observer Pattern体现。Controller控制Views的显示,能够用Strategy Pattern实现。Model一般是一个调停者,可采用Mediator Pattern来实现。 

如今让咱们来了解一下MVC三个部分在J2EE架构中处于什么位置,这样有助于咱们理解MVC模式的实现。MVC与J2EE架构的对应关系是:View处于Web Tier或者说是Client Tier,一般是JSP/Servlet,即页面显示部分。Controller也处于Web Tier,一般用Servlet来实现,即页面显示的逻辑部分实现。Model处于Middle Tier,一般用服务端的javaBean或者EJB实现,即业务逻辑部分的实现。 

1、MVC设计思想 

MVC英文即Model-View-Controller,即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离,这样一个应用被分红三个层——模型层、视图层、控制层。 

视图(View)表明用户交互界面,对于Web应用来讲,能够归纳为HTML界面,但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性,界面的处理也变得具备挑战性。一个应用可能有不少不一样的视图,MVC设计模式对于视图的处理仅限于视图上数据的采集和处理,以及用户的请求,而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。好比一个订单的视图只接受来自模型的数据并显示给用户,以及将用户界面的输入数据和请求传递给控制和模型。 

模型(Model):就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来讲是黑箱操做,模型接受视图请求的数据,并返回最终的处理结果。业务模型的设计能够说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子,它从应用技术实现的角度对模型作了进一步的划分,以便充分利用现有的组件,但它不能做为应用设计模型的框架。它仅仅告诉你按这种模型设计就能够利用某些技术组件,从而减小了技术上的困难。对一个开发者来讲,就能够专一于业务模型的设计。MVC设计模式告诉咱们,把应用的模型按必定的规则抽取出来,抽取的层次很重要,这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远,也不能太近。MVC并无提供模型的设计方法,而只告诉你应该组织管理这些模型,以便于模型的重构和提升重用性。咱们能够用对象编程来作比喻,MVC定义了一个顶级类,告诉它的子类你只能作这些,但无法限制你能作这些。这点对编程的开发人员很是重要。 

业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存(持续化)。好比将一张订单保存到数据库,从数据库获取订单。咱们能够将这个模型单独列出,全部有关数据库的操做只限制在该模型中。 

控制(Controller)能够理解为从用户接收请求, 将模型与视图匹配在一块儿,共同完成用户的请求。划分控制层的做用也很明显,它清楚地告诉你,它就是一个分发器,选择什么样的模型,选择什么样的视图,能够完成什么样的用户请求。控制层并不作任何的数据处理。例如,用户点击一个链接,控制层接受请求后, 并不处理业务信息,它只把用户的信息传递给模型,告诉模型作什么,选择符合要求的视图返回给用户。所以,一个模型可能对应多个视图,一个视图可能对应多个模型。 

模型、视图与控制器的分离,使得一个模型能够具备多个显示视图。若是用户经过某个视图的控制器改变了模型的数据,全部其它依赖于这些数据的视图都应反映到这些变化。所以,不管什么时候发生了何种数据变化,控制器都会将变化通知全部的视图,致使显示的更新。这其实是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能,如图1所示。 
2、MVC设计模式的实现 

ASP.NET提供了一个很好的实现这种经典设计模式的相似环境。开发者经过在ASPX页面中开发用户接口来实现视图;控制器的功能在逻辑功能代码(.cs)中实现;模型一般对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统,较经典的ASP结构实现的系统来讲有明显的优势。将用户显示(视图)从动做(控制器)中分离出来,提升了代码的重用性。将数据(模型)从对其操做的动做(控制器)分离出来可让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言,它是一种解决耦合系统问题的方法。 
2.1 视图 
视图是模型的表示,它提供用户交互界面。使用多个包含单显示页面的用户部件,复杂的Web页面能够展现来自多个数据源的内容,而且网页人员,美工能独自参与这些Web页面的开发和维护。 

在ASP.NET下,视图的实现很简单。能够像开发WINDOWS界面同样直接在集成开发环境下经过拖动控件来完成页面开发本。本文中介绍每个页面都采用复合视图的形式即:一个页面由多个子视图(用户部件)组成;子视图能够是最简单HTML 控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义,模板定义了页面的布局,用户部件的标签和数目,用户指定一个模板,平台根据这些信息自动建立页面。针对静态的模板内容,如页面上的站点导航,菜单,友好连接,这些使用缺省的模板内容配置;针对动态的模板内容(主要是业务内容),因为用户的请求不一样,只能使用后期绑定,而且针对用户的不一样,用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面,它加强了可重用性,并原型化了站点的布局。 

视图部分大体处理流程以下:首先,页面模板定义了页面的布局;页面配置文件定义视图标签的具体内容(用户部件);而后,由页面布局策略类初始化并加载页面;每一个用户部件根据它本身的配置进行初始化,加载校验器并设置参数,以及事件的委托等;用户提交后,经过了表示层的校验,用户部件把数据自动提交给业务实体即模型。 

这一部分主要定义了WEB页面基类PageBase;页面布局策略类PageLayout,完成页面布局,用于加载用户部件到页面;用户部件基类UserControlBase即用户部件框架,用于动态加载检验部件,以及实现用户部件的个性化。为了实现WEB应用的灵活性,视图部分也用到了许多配置文件例如:置文件有模板配置、页面配置、路径配置、验证配置等。 

2.2 控制器 

为了可以控制和协调每一个用户跨越多个请求的处理,控制机制应该以集中的方式进行管理。所以,为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求(典型状况下是一个运行浏览器的用户),决定执行什么商业逻辑功能,而后将产生下一步用户界面的责任委派给一个适当的视图组件。 

用控制器提供一个控制和处理请求的集中入口点,它负责接收、截取并处理用户请求;并将请求委托给分发者类,根据当前状态和业务操做的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等,它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理全部请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类;分发者类分发者负责视图的管理和导航,它管理将选择哪一个视图提供给用户,并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。 

为了使请求捕获者类自动捕获用户请求并进行处理,ASP.NET 提供低级别的请求/响应 API,使开发人员可以使用 .NET 框架类为传入的 HTTP 请求提供服务。为此,必须创做支持 System.Web.IHTTPHandler 接口和实现 ProcessRequest() 方法的类即:请求捕获者类,并在web.config 的 <httphandlers> 节中添加类。ASP.NET 收到的每一个传入 HTTP 请求最终由实现 IHTTPHandler 的类的特定实例来处理。IHttpHandlerFactory 提供了处理 IHttpHandler 实例 URL 请求的实际解析的结构。HTTP 处理程序和工厂在 ASP.NET 配置中声明为 web.config 文件的一部分。ASP.NET 定义了一个 <httphandlers> 配置节,在其中能够添加和移除处理程序和工厂。子目录继承 HttpHandlerFactory 和 HttpHandler 的设置。 HTTP 处理程序和工厂是 ASP.NET 页框架的主体。工厂将每一个请求分配给一个处理程序,后者处理该请求。 例如,在全局 machine.config 文件中,ASP.NET 将全部对 ASPx 文件的请求映射到 HttpCapture类: 

<httphandlers> 
... 
... 
</httphandlers> 
2.3 模型 
MVC系统中的模型从概念上能够分为两类――系统的内部状态和改变系统状态的动做。模型是你全部的商业逻辑代码片断所在。本文为模型提供了业务实体对象和业务处理对象:全部的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑,调用业务逻辑模型,而且把响应提交到合适的视图组件以产生响应。业务实体对象能够经过定义属性描述客户端表单数据。全部业务实体对象都EntityBase派生子类对象,业务处理对象能够直接对它进行读写,而再也不须要和request、response对象进行数据交互。经过业务实体对象实现了对视图和模型之间交互的支持。实现时把"作什么"(业务处理)和"如何作"(业务实体)分离。这样能够实现业务逻辑的重用。因为各个应用的具体业务是不一样的,这里再也不列举其具体代码实例。 
3、MVC设计模式的扩展 
经过在ASP.NET中的MVC模式编写的,具备极其良好的可扩展性。它能够轻松实现如下功能: 

①实现一个模型的多个视图; 
②采用多个控制器; 
③当模型改变时,全部视图将自动刷新; 
④全部的控制器将相互独立工做。 
这就是MVC模式的好处,只需在之前的程序上稍做修改或增长新的类,便可轻松增长许多程序功能。之前开发的许多类能够重用,而程序结构根本再也不须要改变,各种之间相互独立,便于团体开发,提升开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不须要改变,与前面的彻底同样,这就是面向对象编程的好处。对于控制器中的类,只须要增长另外一个视图,并与模型发生关联便可。该模式下视图、控制器、模型三者之间的示意图如图2所示。 
一样也能够实现其它形式的MVC例如:一个模型、两个视图和两个控制器。从上面能够看出,经过MVC模式实现的应用程序具备极其良好的可扩展性,是ASP.NET面向对象编程的将来方向。 
4、MVC的优势 
大部分用过程语言好比ASP、PHP开发出来的Web应用,初始的开发模板就是混合层的数据编程。例如,直接向数据库发送请求并用HTML显示,开发速度每每比较快,但因为数据页面的分离不是很直接,于是很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小,很难知足用户的变化性需求。MVC要求对应用分层,虽然要花费额外的工做,但产品的结构清晰,产品的应用经过模型能够获得更好地体现。 

首先,最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下,可能有多种方式访问应用的要求。例如,订单模型可能有本系统的订单,也有网上订单,或者其余系统的订单,但对于订单的处理都是同样,也就是说订单的处理是一致的。按MVC设计模式,一个订单模型以及多个视图便可解决问题。这样减小了代码的复制,即减小了代码的维护量,一旦模型发生改变,也易于维护。 其次,因为模型返回的数据不带任何显示格式,于是这些模型也可直接应用于接口的使用。 

再次,因为一个应用被分离为三层,所以有时改变其中的一层就能知足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。 

控制层的概念也颇有效,因为它把不一样的模型和不一样的视图组合在一块儿完成不一样的请求,所以,控制层能够说是包含了用户请求权限的概念。 
最后,它还有利于软件工程化管理。因为不一样的层各司其职,每一层不一样的应用具备某些相同的特征,有利于经过工程化、工具化产生管理程序代码。 
5、MVC的不足 
MVC的不足体如今如下几个方面: 
(1)增长了系统结构和实现的复杂性。对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增长结构的复杂性,并可能产生过多的更新操做,下降运行效率。 
(2)视图与控制器间的过于紧密的链接。视图与控制器是相互分离,但确实联系紧密的部件,视图没有控制器的存在,其应用是颇有限的,反之亦然,这样就妨碍了他们的独立重用。 
(3)视图对模型数据的低效率访问。依据模型操做接口的不一样,视图可能须要屡次调用才能得到足够的显示数据。对未变化数据的没必要要的频繁访问,也将损害操做性能。 
(4) 目前,通常高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC须要和创建分离的部件的代价是很高的,从而形成使用MVC的困难java

相关文章
相关标签/搜索