Xiangge_Asp.Net

路慢慢其修远兮,吾将上下而求索
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

(转)浅谈ASP.NET MVC及IoC模式

Posted on 2008-10-07 10:12  谢作祥  阅读(1149)  评论(0)    收藏  举报
    ASP.NET MVC是微软最新推出的新型体系结构.NET框架的一部分,它为构造新一代动态网站和基于网络的分布式应用提供了强有力的支持。与以前的 Web 开发模型相比,ASP.NET 提供了许多重要的优点例如: 简易性;安全性;可管理性等。而且与基于过程的ASP页面技术相比,面向对象技术在ASP.NET中得到了完全实现。用传统ASP技术建立的Web应用实例中,在页面中同时实现显示,业务逻辑和流程控制,这从工程化的角度考虑,它有许多不足之处。用户界面承担着向用户显示问题模型和与用户进行操作和I/O交互的作用。用户希望保持交互操作界面的相对稳定,但更希望根据需要改变和调整显示的内容和形式。在.NET框架下ASP.NET技术结合MVC设计模式很好地解决了上述问题。起初mvc并不是微软的东东,而是由java领域所发起的。

    MVC作为一种开发模型,通常用于分布式应用系统的设计和分析中,以及用于确定系统各部分间的组织关系。对于界面设计可变性的需求,MVC(Model-View-Controller)把交互系统的组成分解成模型、视图、控制器三种部件。
  视图部件把表示模型数据及逻辑关系和状态的信息以特定形式展示给用户。它从模型获得显示信息,对于相同的信息可以有多个不同的显示形式或视图。
  控制器部件是处理用户与软件的交互操作的,其职责是控制提供模型中任何变化的传播,确保用户界面于模型间的对应联系;它接受用户的输入,将输入反馈给模型,进而实现对模型的计算控制,是使模型和视图协调工作的部件。
  模型部件保存由视图显示,由控制器控制的数据;它封装了问题的核心数据、逻辑和功能的计算关系,它独立于具体的界面表达和I/O操作。
  模型、视图与控制器的分离,使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据,所有其它依赖于这些数据的视图都应反映到这些变化。因此,无论何时发生了何种数据变化,控制器都会将变化通知所有的视图,导致显示的更新。这实际上是一种模型的变化-传播机制。
    模型、视图、控制器三者之间的关系和各自的主要功能,如图1所示:

   

     ASP.NET MVC提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现视图;控制器的功能在逻辑功能代码(.cs)中实现;模型通常对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统,较经典的ASP结构实现的系统来说有明显的优点。将用户显示(视图)从动作(控制器)中分离出来,提高了代码的重用性。将数据(模型)从对其操作的动作(控制器)分离出来可以让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言,它是一种解决稀释耦合系统的方法。


视图(Views)
    视图是模型的表示,它提供用户交互界面。使用多个包含单显示页面的用户部件,复杂的Web页面可以展示来自多个数据源的内容,并且网页人员,美工能独自参与这些Web页面的开发和维护,提高了开发效率。
  在ASP.NET下,视图的实现很简单。可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。本文中介绍每一个页面都采用复合视图的形式即:一个页面由多个子视图组成;子视图可以是最简单HTML控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义,模板定义了页面的布局,用户部件的标签和数目,用户指定一个模板,平台根据这些信息自动创建页面。针对静态的模板内容,如页面上的站点导航,菜单,友好链接,这些使用缺省的模板内容配置;针对动态的模板内容(主要是业务内容),由于用户的请求不同,只能使用后期绑定,并且针对用户的不同,用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面,它增强了可重用性,并原型化了站点的布局。
  视图部分大致处理流程如下:首先,页面模板定义了页面的布局;页面配置文件定义视图标签的具体内容(用户部件);然后,由页面布局策略类初始化并加载页面;每个用户部件根据它自己的配置进行初始化,加载校验器并设置参数,以及事件的委托等;用户提交后,通过了表示层的校验,用户部件把数据自动提交给业务实体即模型。
  这一部分主要定义了WEB页面基类PageBase;页面布局策略类PageLayout,完成页面布局,用于加载用户部件到页面;用户部件基类UserControlBase即用户部件框架,用于动态加载检验部件,以及实现用户部件的个性化。为了实现WEB应用的灵活性,视图部分也用到了许多配置文件例如:配置文件有模板配置、页面配置、路径配置、验证配置等。

控制器(Controllers)
    为了能够控制和协调每个用户跨越多个请求的处理,控制机制应该以集中的方式进行管理。因此,为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求,决定执行什么商业逻辑功能,然后将产生下一步用户界面的责任委派给一个适当的视图组件。
  用控制器提供一个控制和处理请求的集中入口点,它负责接收、截取并处理用户请求;并将请求委托给分发者类,根据当前状态和业务操作的结果决定向客户呈现的视图。在这一部分主要定义了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>
...
<add verb="*" path="*.ASPx" type="Sys.UI.HttpCapture, Sys.UI"/>
...
</httphandlers>

模型(Models)
    MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。模型是你所有的业务逻辑代码片段所在。本文为模型提供了业务实体对象和业务处理对象:所有的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑,调用业务逻辑模型,并且把响应提交到合适的视图组件以产生响应。业务实体对象可以通过定义属性描述客户端表单数据。所有业务实体对象都EntityBase派生子类对象,业务处理对象可以直接对它进行读写,而不再需要和request、response对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"(业务处理)和"如何做"(业务实体)分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的,这里不再列举其具体代码实例。
  通过在ASP.NET中的MVC模式编写的,具有极其良好的可扩展性,具有低耦合的效果。它可以轻松实现以下功能:
  ①实现一个模型的多个视图;
  ②采用多个控制器;
  ③当模型改变时,所有视图将自动刷新;
  ④所有的控制器将相互独立工作。
  该模式下视图、控制器、模型三者之间的示意图如图2所示:

    

     同样也可以实现其它形式的MVC例如:一个模型、两个视图和两个控制器。通过MVC模式实现的应用程序具有极其良好的可扩展性,是ASP.NET面向对象编程的未来方向。

IoC(Inversion of Control)控制反转容器
    IoC将处理事情的责任从应用程序代码转移到框架,在软件开发技术中是一种通过容器管理对象约束关系。控制反转意味着在系统开发过程中,设计的类将交由容器去控制,而不是在类的内部去控制,类与类之间的关系将交由容器处理,一个类在需要调用另一个类时,只要调用另一个类在容器中注册的名字就可以得到这个类的实例,与传统的编程方式有了很大的不同,”不用你找,我来提供给你”,这就是控制反转的含义。
IOC的机制是:处理类之间和接口之间或类与接口之间关联关系,调用着与被调用者的主次关系,实现开关的原则。类之间可以很好(甚至)可以完全避免耦合,一个类只负责自己逻辑功能代码,如果想调用其它类告诉IOC容器去做(一种比较好的方式是根据配置文件来设定复杂关系),而不需要在代码上过多的编写。


MVC设计模式的优点及不足之处
  MVC的优点体现在以下几个方面:
  (1) 可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化,从而使所有关联的视图和控制器做到行为同步。
  (2) 视图与控制器的可接插性,允许更换视图和控制器对象,而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。
  (3) 模型的可移植性。因为模型是独立于视图的,所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。
  (4) 潜在的框架结构。可以基于此模型建立应用程序框架,不仅仅是用在设计界面的设计中。

  MVC的不足体现在以下几个方面:
  (1)增加了系统结构和实现的复杂性。对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率。
  (2)视图与控制器间的过于紧密的连接。视图与控制器是相互分离,但确实联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
  (3)视图对模型数据的低效率访问。依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问,也将损害操作性能。
  (4) 目前,一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的,从而造成使用MVC的困难。


    MVC对我来说,我也学习了有段时间了,结合了ASP.NET MVC Preview 2和ASP.NET MVC Preview 3两个Demo来学习微软提供的新框架,分析他们的不同之处,可以说这里面应用了很多新技术,例如Ajax、Linq、设计模式、页面跳转,还可以加入Web Service,这些技术和思想,我认为当你对MVC思想成熟时,也可以用在WinForm的开发中,虽然说其中有缺点,也有优点。与软件所处理问题的内在模型相比较,用户界面是需要经常发生变化的,采用MVC设计模式可以在满足对界面要求的同时,使软件的计算模型独立于界面的构成。也可以基于此模型建立大型分布式应用程序框架。最近经过本人的努力,已将MVC应用于一对外项目上,并且囊括了Ajax、设计模式、泛型程式一些技术,在此基础上,经过努力完成了对家庭理财软件的移植技术,我想这是我最近一段时间来最大的欣慰和回报。