mvc模式.htm

介绍了MVC的很多内容（基于MVC模式Struts框架研究与应用详解—JSP教程

target=_new>数据库</A>，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。 </FONT></P>
<P><FONT face=Verdana>　　控制(Controller)可以理解为从用户接收请求, 
将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 
并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。 
</FONT></P>
<P>模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。 
<BR></P>
<P align=center><IMG src="MVC模式.files/2006327211638498.gif" border=0></P>
<P><FONT face=Verdana><STRONG>二、MVC设计模式的实现</STRONG> </P>
<P>　　ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来说有明显的优点。将用户显示（视图）从动作（控制器）中分离出来,提高了代码的重用性。将数据（模型）从对其操作的动作（控制器）分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决耦合系统问题的方法。</P>
<P>　　2.1 视图</P>
<P>　　视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面可以展示来自多个数据源的内容，并且网页人员，美工能独自参与这些Web页面的开发和维护。</P>
<P>　　在ASP.NET下，视图的实现很简单。可以像开发WINDOWS界面一样直接在<A 
href="http://www.itisedu.com/phrase/200604261453255.html" 
target=_new>集成开发环境</A>下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即：一个页面由多个子视图(用户部件)组成；子视图可以是最简单HTML 
控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动创建页面。针对静态的模板内容，如页面上的站点导航，菜单，友好链接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，由于用户的请求不同，只能使用后期绑定，并且针对用户的不同，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它增强了可重用性，并原型化了站点的布局。</P>
<P>　　视图部分大致处理流程如下：首先，页面模板定义了页面的布局；页面配置<A 
href="http://www.itisedu.com/phrase/200602282323195.html" 
target=_new>文件</A>定义视图标签的具体内容（用户部件）；然后，由页面布局策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的校验，用户部件把数据自动提交给<A 
href="http://www.itisedu.com/phrase/200603101513085.html" 
target=_new>业务实体</A>即模型。</P>
<P>　　这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：置文件有模板配置、页面配置、路径配置、验证配置等。</P>
<P>　　2.2 控制器</P>
<P>　　为了能够控制和协调每个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。因此，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从<A 
href="http://www.itisedu.com/phrase/200603082208195.html" 
target=_new>客户端</A>接收请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。</P>
<P>　　用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理所有请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。</P>
<P>　　为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET 提供低级别的请求/响应 <A 
href="http://www.itisedu.com/phrase/200604241228185.html" 
target=_new>API</A>，使开发人员能够使用 .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类： </P>
<P>＜httphandlers＞<BR>...<BR>...<BR>＜/httphandlers＞</P>
<P>　　2.3 模型</P>
<P>　　MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的商业逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象：所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象，业务处理对象可以直接对它进行读写，而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。</P>
<P><STRONG>三、MVC设计模式的扩展</STRONG> </P>
<P>　　通过在ASP.NET中的MVC模式编写的，具有极其良好的可扩展性。它可以轻松实现以下功能：</P>
<P>　　①实现一个模型的多个视图；</P>
<P>　　②采用多个控制器；</P>
<P>　　③当模型改变时，所有视图将自动刷新；</P>
<P>　　④所有的控制器将相互独立工作。</P>
<P 
align=left>　　这就是MVC模式的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是<A 
href="http://www.itisedu.com/phrase/200603050951565.html" 
target=_new>面向对象编程</A>的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。<BR></P>
<P align=center><IMG src="MVC模式.files/200632721174159.gif" border=0><BR></P>
<P>　　同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC模式实现的应用程序具有极其良好的可扩展性，是ASP.NET<A 
href="http://www.itisedu.com/phrase/200603101726185.html" 
target=_new>面向对象</A>编程的未来方向。<BR></P></FONT>
<P><FONT face=Verdana><STRONG>四、MVC的优点</STRONG></FONT></P>
<P><FONT face=Verdana>　　大部分用过程语言比如ASP、<A 
href="http://www.itisedu.com/phrase/200604241503425.html" 
target=_new>PHP</A>开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性<A 
href="http://www.itisedu.com/phrase/200603101518295.html" 
target=_new>需求</A>。MVC要求对应用<A 
href="http://www.itisedu.com/phrase/200604161254415.html" 
target=_new>分层</A>，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。 </FONT></P>
<P><FONT 
face=Verdana>　　首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 
其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。 </FONT></P>
<P><FONT 
face=Verdana>　　再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。 
</FONT></P>
<P><FONT 
face=Verdana>　　控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。 
</FONT></P>
<P><FONT face=Verdana>　　最后，它还有利于<A 
href="http://www.itisedu.com/phrase/200602281725525.html" 
target=_new>软件工程</A>化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。</FONT></P>
<P><FONT face=Verdana><STRONG>五、MVC的不足</STRONG> </P>
<P>　　MVC的不足体现在以下几个方面：</P>
<P>　　（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。</P>
<P>　　（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。</P>
<P>　　（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。</P>
<P>　　（4） 
目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。</P></FONT></DIV></BODY></HTML>