mvc设计模式简介,什么是MVC设计模式，如何使用MVC
mvc设计模式简介,什么是MVC设计模式，如何使用MVC详细介绍
本文目录一览： 什么是MVC设计模式？
MVC是一种目前广泛流行的软件设计模式，早在70年代，IBM就推出了Sanfronscisico项目计划，其实就是MVC设计模式的研究。近来，随着J2EE的成熟，它正在成为在J2EE平台上推荐的一种设计模型，也是广大Java开发者非常感兴趣的设计模型。MVC模式也逐渐在PHP和ColdFusion开发者中运用，并有增长趋势。随着网络应用的快速增加,MVC模式对于Web应用的开发无疑是一种非常先进的设计思想，无论你选择哪种语言，无论应用多复杂,它都能为你理解分析应用模型时提供最基本的分析方法，为你构造产品提供清晰的设计框架，为你的软件工程提供规范的依据。
MVC设计思想
MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求,将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后,并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
MVC的优点大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。
首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。
MVC设计模型
其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。
再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。
MVC的缺点MVC的设计实现并不十分容易,理解起来比较容易，但对开发人员的要求比较高。MVC只是一种基本的设计思想，还需要详细的设计规划。
模型和视图的严格分离可能使得调试困难一些，但比较容易发现错误。
经验表明，MVC由于将应用分为三层，意味着代码文件增多，因此，对于文件的管理需要费点心思。
综合上述，MVC是构筑软件非常好的基本模式，至少将业务处理与显示分离，强迫将应用分为模型、视图以及控制层,使得你会认真考虑应用的额外复杂性，把这些想法融进到架构中，增加了应用的可拓展性。如果能把握到这一点，MVC模式会使得你的应用更加强壮，更加有弹性，更加个性化。
MVC就是M:Model模型V:View视图C:Controller控制器模型就是封装业务逻辑和数据的一个一个的模块,控制器就是调用这些模块的(java中通常是用Servlet来实现,框架的话很多是用Struts2来实现这一层),视图就主要是你看到的,比如JSP等.当用户发出请求的时候,控制器根据请求来选择要处理的业务逻辑和要选择的数据,再返回去把结果输出到视图层,这里可能是进行重定向或转发等.MVC我感觉主要就是把一个软件或网站清晰地分成几部分,每一部分都实现自己的功能,当某一部分需要修改时就可以只修改这一部分,不会去修改整体,当后期维护的时候MVC的作用也是很大的,耦合度太高就会导致牵一发而动全身,开销也就会非常大了,现在的很多软件都是要很多人完成的,不过不把软件清晰的分层,不把软件模块化,大家就很难做好自己的那一块,好多人都可能做了同一部分,而且没办法整合到一起,所以MVC我感觉是一种软件架构思想,我也是新手,可能理解的不是很深,我就把我体会到的说了一下哈,希望大牛们批评更正哈!!!
mvc设计模式怎么理解？
mvc设计模式解释：出现不仅实现了功能模块和显示模块的分离，同时它还提高了应用系统的可维护性、可扩展性、可移植性和组件的可复用性。
1、MVC、是模型视图控制器的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。
2、MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
3、MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。
4、MVC是一个框架模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件:模型、视图、控制器。
什么是mvc模式
分类: 电脑/网络 >> 反病毒
解析:
MVC(Model/View/Controller)模式是国外用得比较多的一种设计模式，好象最早是在Smaltalk中出现。MVC包括三类对象。Model是应用对象，View是它在屏幕上的表示，Controller定义用户界面对用户输入的响应方式。
模型-视图-控制器（MVC）是80年代Smalltalk-80出现的一种软件设计模式，现在已经被广泛的使用。
1、模型（Model）
模型是应用程序的主体部分。模型表示业务数据，或者业务逻辑.
2、视图（View）
视图是应用程序中用户界面相关的部分，是用户看到并与之交互的界面。
3、控制器（controller)
控制器工作就是根据用户的输入，控制用户界面数据显示和更新model对象状态。
MVC 式的出现不仅实现了功能模块和显示模块的分离，同时它还提高了应用系统的可维护性、可扩展性、可移植性和组件的可复用性
早期的程序中，如果不注意对数功能和显示的解耦合，常常会导致程序的复杂及难以维护。很多VB,Delphi等RAD程序都有这种问题。甚至现在的C#,Java有时候也会出现把业务逻辑写在显示模块中的现象
管MVC设计模式很早就提出，但在Web项目的开发中引入MVC却是步履维艰。主要原因：一是在早期的Web项目的开发中，程序语言和HTML的分离一直难以实现。CGI程序以字符串输出的形式动态地生成HTML内容。后来随着脚本语言的出现，前面的方式又被倒了过来，改成将脚本语言书写的程序嵌入在HTML内容中。这两种方式有一个相同的不足之处即它们总是无法将程序语言和HTML分离。二是脚本语言的功能相对较弱，缺乏支持MVC设计模式的一些必要的技术基础。直到基于J2EE的JSP Model 2问世时才得以改观。它用JSP技术实现视图的功能，用Servlet技术实现控制器的功能，用JavaBean技术实现模型的功能
JSP Model 1 与 JSP Model 2
SUN在JSP出现早期制定了两种规范，称为Model1和Model2。虽然Model2在一定程度上实现了MVC，但是它的应用用并不尽如人意
JSP Model 1
JSP Model 2
model2 容易使系统出现多个Controller，并且对页面导航的处理比较复杂
有些人觉得model2仍不够好，于是Craig R. McClanahan 2000年5月提交了一个WEB framework给Java Community.这就是后来的Struts.
2001年7月，Struts1.0，正式发布。该项目也成为了Apache Jakarta的子项目之一
Struts 质上就是在Model2的基础上实现的一个MVC架构。它只有一个中心控制器，他采用XML定制转向的URL。采用Action来处理逻辑
什么是MVC模式？
MVC是三个单词的缩写，分别为： 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。 View层用于与用户的交互，通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。分层概念视图视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services. 如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
模型模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如它可能用象EJBs和ColdFusion Components这样的构件对象来处理数据库。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。
什么是MVC设计模式，如何使用MVC
MVC模式解释，以及如何使用mvc的解释如下：
模型-视图-控制器（MVC模式）是一种非常经典的软件架构模式，在UI框架和UI设计思路中扮演着非常重要的角色。从设计模式的角度来看，MVC模式是一种复合模式，它将多个设计模式在一种解决方案中结合起来，用来解决许多设计问题。MVC模式把用户界面交互分拆到不同的三种角色中，使应用程序被分成三个核心部件：Model（模型）、View（视图）、Control（控制器）。它们各自处理自己的任务：
（1）模型：模型持有所有的数据、状态和程序逻辑。模型独立于视图和控制器。
（2）视图：用来呈现模型。视图通常直接从模型中取得它需要显示的状态与数据。对于相同的信息可以有多个不同的显示形式或视图。
（3）控制器：位于视图和模型中间，负责接受用户的输入，将输入进行解析并反馈给模型，通常一个视图具有一个控制器。
MVC将程序分为3个核心模块：模型(Model)、视图(View)和控制器(Controller)。
控制器（Controller）
控制器是负责应用程序中处理用户交互的部分，它负责从视图中读取数据，控制用户输入并向模型发送数据。由Servlet完成。
模型（Model）
模型负责管理应用程序的业务数据（JavaBean）以及定义访问控制和修改这些数据的业务规则（Dao包括对数据库的增、删、改、查方法）。当模型的状态发生改变时，它会通知视图发生改变，并为视图提供查询模型状态的方法。
视图（View）
视图负责与用户进行交互，它从模型中获取数据向用户展示，同时也能将用户请求传递给控制器进行处理。当模型的状态发生改变时，视图会对用户界面进行同步更新，从而保持与模型数据的一致性。由JSP完成。
MVC模式的工作流程：浏览器发起请求，控制器接收到用户的请求后，将请求数据封装到JavaBean对象中，然后根据请求信息调用模型组件的业务方法Dao，并将JavaBean对象传递给Dao，控制器调用模型组件处理完毕后，根据模型的返回结果选择相应的视图组件来显示处理结果和模型中的数据。
MVC是Model,View,Controller的缩写,MVC是Application开发的设计模式，也就是大家所知道的Model2.在MVC的设计模式中，它包括三类对象：（1）模型（Model）对象：是应用程序的主体部分。（2）视图（View）对象：是应用程序中负责生成用户界面的部分。（3）控制器（Control）对象：是根据用户的输入，控制用户界面数据显示及更新Model对象状态的部分。即要求在Application开发中你把商业逻辑，界面显示，数据分离。 MVC应用程序总是由三个部分组成.Event(事件)导致Controller改变Model或View,或者同时改变两者.只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新.类似的,只要Controller改变了View，View会从潜在的Model中获取数据来刷新自己 MVC模式是一个复杂的架构模式,其实现也显得非常复杂,但多种设计模式结合在一起,使MVC模式的实现变得相对简单易行.Views可以看作一棵树,显然可以用Composite Pattern来实现.Views和Models之间的关系可以用Observer Pattern体现.Controller控制Views的显示,可以用Strategy Pattern实现.Model通常是一个调停者,可采用Mediator Pattern来实现. Java开发Web Application有几种符合MVC设计模式的开发方式。 1:Jsp+Servlet+JavaBean(EJB) 2:Jsp+JavaBean(Controller)+JavaBean(EJB)(Model) 3:TDK(Turbine，Velocity...) 4:Xsp 5:Jsp+Struts+JavaBean(EJB)
什么是MVC模式？？？
MVC模式是"Model-View-Controller"的缩写,它是一种程序设计模式。我简单说一下，Model相当于数据等内容，View想当于用户界面等，而Controller就用来控制Model跟View。
详细参考：http://www.itisedu.com/phrase/200604231324325.html
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实现，即业务逻辑部分的实现。
一、MVC设计思想
MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。
二、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对象进行数据交互。通过业务实体对象实现了对视图和模型之间交互的支持。实现时把"做什么"（业务处理）和"如何做"（业务实体）分离。这样可以实现业务逻辑的重用。由于各个应用的具体业务是不同的，这里不再列举其具体代码实例。
三、MVC设计模式的扩展
通过在ASP.NET中的MVC模式编写的，具有极其良好的可扩展性。它可以轻松实现以下功能：
①实现一个模型的多个视图；
②采用多个控制器；
③当模型改变时，所有视图将自动刷新；
④所有的控制器将相互独立工作。
这就是MVC模式的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。下面讨论如何实现一个模型、两个视图和一个控制器的程序。其中模型类及视图类根本不需要改变，与前面的完全一样，这就是面向对象编程的好处。对于控制器中的类，只需要增加另一个视图，并与模型发生关联即可。该模式下视图、控制器、模型三者之间的示意图如图2所示。
同样也可以实现其它形式的MVC例如：一个模型、两个视图和两个控制器。从上面可以看出，通过MVC模式实现的应用程序具有极其良好的可扩展性，是ASP.NET面向对象编程的未来方向。
四、MVC的优点
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。 MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。
首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。
再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。
五、MVC的不足
MVC的不足体现在以下几个方面：
（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
什么是MVC？
MVC是三个单词的缩写,分别为：
模型(Model),视图(View)和控制Controller)。
MVC模式的目的就是实现Web系统的职能分工。
Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。
View层用于与用户的交互，通常用JSP来实现。
Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。
MVC是三个单词的缩写,分别为：
模型(Model),视图(View)和控制Controller)。
MVC模式的目的就是实现Web系统的职能分工。
Model层实现系统中的业务逻辑，通常可以用JavaBean或EJB来实现。
View层用于与用户的交互，通常用JSP来实现。
Controller层是Model与View之间沟通的桥梁，它可以分派用户的请求并选择恰当的视图以用于显示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
MVC（模型Model-视图View-控制器Controller）是一种设计模式，
MVC。V即View.是视图的意思。C即Controller.是控制器的意思。而M即Model，是模型的意思。这三个里.最不容易理解的应该是Model.就是什么是Model，而为什么叫Model。我先不说为什么叫Model，先解释Controller。
Controller是控制器的意思，所谓控制器，就是将用户请求转发给模型层，经过处理后把结果返回到界面层展现的一个中间层，那么Controller到底管什么工作呢？先不说.先来看下在Java
Web中这三个层一般的定义，一般在Java
Web里，JSP充当V，Servlet充当C,JavaBean充当M，这里的Servlet管什么工作呢？接受输入，转到Model层去处理，处理结果保存后转发到JSP，然后展现数据。所以它的功能就是控制器的基本功能，它就管转发，在V和M之间转来转去。
再来说说M，即Model，在Java
Web里说的是JavaBean，我认识的很多人都把JavaBean误认为是实体类，其实JavaBean有比实体类更丰富的定义，在JavaBean中除了其属性和字段，还可以有行为及其事件，JavaBean可以理解为普通Java对象。Java普通对象，就是符合Java规范的所有对象，这和实体类完全是两回事。所以，我认为在MVC中。业务逻辑和数据访问应该放在Model层，也就是V负责展示数据，Controler除了转发不做业务逻辑。真正的逻辑事务，数据访问，甚至算法都放到Model去。
MVC没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是已实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的
MVC设计模式是什么？怎么理解？
什么是MVP
View ：是指显示数据并且和用户交互的层。在安卓中，它们可以是一个Activity，一个Fragment，一个android.view.View或者是一个Dialog。
Model ：是数据源层。比如数据库接口或者远程服务器的api。
Presenter：是从Model中获取数据并提供给View的层，Presenter还负责处理后台任务。
MVP是一个将后台任务和activities/views/fragment分离的方法，让它们独立于绝大多数跟生命周期相关的事件。这样应用就会变得更简单，整个应用的稳定性提高10倍以上，代码也变得更短，可维护性增强，程序员也不会过劳死了~~。
为什么要在安卓上使用MVP原因一: 尽量简单
如果你还没有阅读过这篇文章，阅读它: Kiss原则(https://people.apache.org/%7Efhanik/kiss.html)。- kiss是Keep It Stupid Simple或者Keep It Simple, Stupid的缩写。
.绝大多数的安卓程序都只使用了View-Model架构。
.程序员被绞尽了复杂的界面开发中，而不是解决事务逻辑。
在应用中使用Model-View的坏处是“每个东西之间都是相互关联的”如下图:
如果上面的图解看起来还不够复杂，那么想想这些情况：每个view可能在任意的时间出现或者消失，view数据需要保存与恢复，在临时的view上挂载一个后台任务。
而与“每个东西之间都是相互关联的”的相反选择是使用一个万能对象（god object）。注：god object是指一个对象/例程在系统中做了太多的事情，或者说是有太多不怎么相关的事情放在一个对象/例程里面来完成。
god object过于复杂，他的不同部分无法重用、测试，无法轻易的debug和重构。
使用MVP
复杂的任务被分割成简单的任务。
.更小的对象，更少的bug。
.更好测试
MVP的view层变得如此简单，在请求数据的时候甚至不需要使用回调。view的逻辑变得非常直接。
原因二: 后台任务
当你需要写一个Activity，Fragment或者一个自定义View的时候，你可以将所有和后台任务相关的方法放在一个外部的或者静态的类中。这样你的后台任务就不会再与Activity相关联，不会在泄漏内存同时也不会依赖于Activity的重建。我们称这样的一个类为“Presenter”。注：要理解此话的含义最好先看懂第一个MVP示例的代码。
虽然有一些方法可以解决后台任务的问题，但是没有一种和MVP一样可靠。
为什么这是可行的
下面的图解显示了在configuration改变或者发生out-of-memory事件的情况下应用的不同部分所发生的事情。每一个开发者都应该知道这些数据，但是这些数据并不好发现。
| Case 1 | Case 2 | Case 3
|A configuration| An activity | A process
| change | restart | restart
---------------------------------------- | ------------- | ------------ | ------------
Dialog | reset | reset | reset
Activity, View, Fragment | save/restore | save/restore | save/restore
Fragment with setRetainInstance(true) | no change | save/restore | save/restore
Static variables and threads | no change | no change | reset
情景1：configuration的改变通常发生在旋转屏幕，修改语言设置，链接外部的模拟器等情况下。要知道更多的configuration change事件请阅读：configChanges（developer.android.com/reference/android/R.attr.html#configChanges）。
情景2：Activity的重启发生在当用户在开发者选项中选中了“Don't keep activities”（“中文下为 不保留活动”）的复选框，然后另一个Activity在最顶上的时候。
情景3：进程的重启发生在应用运行在后台，但是这个时候内存不够的情况下。
结论
现在你可以发现，一个拥有setRetainInstance(true)的Fragment并没有带来帮助 - 我们还是要保存和/恢复这种fragment的状态。因此我们可以去掉可保持Fragment的情景，把问题简单化。Occam's razor（https://en.wikipedia.org/wiki/Occam%27s_razor）
MVC是Model－View－Controller的简写。
M：model 应用的业务逻辑（通过JavaBean，EJB组件实现）
V：View 应用的表示面（由JSP页面产生）
C：Controller 提供应用的处理过程控制（一般是一个Servlet），
通过这种设计模型把应用逻辑，处理过程和显示逻辑分成不同的组件实现。
这些组件可以进行交互和重用。
MVC就是
M:Model 模型
V:View 视图
C:Controller 控制器
模型就是封装业务逻辑和数据的一个一个的模块,控制器就是调用这些模块的(java中通常是用Servlet来实现,框架的话很多是用Struts2来实现这一层),视图就主要是你看到的,比如JSP等.
当用户发出请求的时候,控制器根据请求来选择要处理的业务逻辑和要选择的数据,再返回去把结果输出到视图层,这里可能是进行重定向或转发等.MVC我感觉主要就是把一个软件或网站清晰地分成几部分,每一部分都实现自己的功能,当某一部分需要修改时就可以只修改这一部分,不会去修改整体,当后期维护的时候MVC的作用也是很大的,耦合度太高就会导致牵一发而动全身,开销也就会非常大了,现在的很多软件都是要很多人完成的,不过不把软件清晰的分层,不把软件模块化,大家就很难做好自己的那一块,好多人都可能做了同一部分,而且没办法整合到一起,所以MVC我感觉是一种软件架构思想,我也是新手,可能理解的不是很深,我就把我体会到的说了一下哈,希望大牛们批评更正哈!!!
什么是MVC设计模式，为什么使用MVC？
MVC(Model-View-Controller)把系统的组成分解为M（模型）、 V（视图）、C（控制器）三种部件。视图表示数据在屏幕上的显示。控制器提供处理过程控制，它在模型和视图之间起连接作用。控制器本身不输出任何信息和做任何处理，它只负责把用户的请求转成针对Model的操作，和调用相应的视图来显示Model处理后的数据。
用户界面逻辑的更改往往比业务逻辑频繁，尤其是在基于Web的应用程序中。例如，可能添加新的用户界面页，或者可能完全打乱现有的页面布局。对显示的更改，尽可能地不要影响到数据和业务逻辑。
目前大部分Web应用都是将数据代码和表示混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制性的将它们分开。尽管构造MVC应用需要一些额外的工作，但它带来的好处是无庸质疑的