跳转到内容

MVC：修订间差异

本页使用了标题或全文手工转换
维基百科，自由的百科全书
以互动方式浏览历史
←上一版本下一版本→
删除的内容 添加的内容
可视化wikitext
Jobinson99（留言 | 贡献）
32次编辑
无编辑摘要
Jobinson99（留言 | 贡献）
32次编辑
无编辑摘要
第4行： 第4行：
|1=zh-hans:直观; zh-hant:直覺;
|1=zh-hans:直观; zh-hant:直覺;
}}
}}
'''MVC'''（Model模型-View视图-Controller控制器，——筋骨皮模式）是[[软件工程]]中的一种[[软件架构]]模式。它把软件系统分为三个基本部分：骨架（Model模型），表皮（View视图）和筋（Controller控制器）。
'''筋骨皮模式'''（Model模型-View视图-Controller控制器）是[[软件工程]]中的一种[[软件架构]]模式。它把软件系统分为三个基本部分：骨架（Model模型），表皮（View视图）和筋（Controller控制器）。


筋骨皮模式最早由[[Trygve Reenskaug]]在1974年<ref>[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Trygve M. H. Reenskaug/MVC]—XEROX PARC 1978-79</ref>提出，是[[帕罗奥多研究中心|施乐帕罗奥多研究中心]]（Xerox PARC）在20世纪80年代为程序语言[[Smalltalk]]发明的一种软件设计模式。'''筋骨皮模式'''的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外此模式通过对复杂度的简化使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：
筋骨皮模式最早由[[Trygve Reenskaug]]在1974年<ref>[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Trygve M. H. Reenskaug/MVC]—XEROX PARC 1978-79</ref>提出，是[[帕罗奥多研究中心|施乐帕罗奥多研究中心]]（Xerox PARC）在20世纪80年代为程序语言[[Smalltalk]]发明的一种软件设计模式。'''筋骨皮模式'''的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外此模式通过对复杂度的简化使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：

2010年4月12日 (一) 18:49的版本

筋骨皮模式（Model模型-View视图-Controller控制器）是软件工程中的一种软件架构模式。它把软件系统分为三个基本部分：骨架（Model模型），表皮（View视图）和筋（Controller控制器）。

筋骨皮模式最早由Trygve Reenskaug在1974年[1]提出，是施乐帕罗奥多研究中心（Xerox PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件设计模式。筋骨皮模式的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外此模式通过对复杂度的简化使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：

  • 筋（控制器）- 负责转发请求，对请求进行处理。
  • 表皮（视图） - 界面设计人员进行图形界面设计。
  • 骨架（模型） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

层次

骨架（Model模型） “数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。（比较：观察者模式（软件设计模式））

外皮（View视图） 视图层能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。

筋（Controller控制器） 控制器起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。

优点

在最初的JSP网页中，像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心地计划和不断的尝试。筋骨皮模式从根本上强制性地将它们分开。尽管构造筋骨皮模式应用程序需要一些额外的工作，但是它带给我们的好处是毋庸置疑的。

首先，多个视图能共享一个模型。如今，同一个Web应用程序会提供多种用户界面，例如用户希望既能够通过浏览器来收发电子邮件，还希望通过手机来访问电子邮箱，这就要求Web网站同时能提供Internet界面和WAP界面。在筋骨皮设计模式中，模型响应用户请求并返回响应数据，视图负责格式化数据并把它们呈现给用户，业务逻辑和表示层分离，同一个模型可以被不同的视图重用，所以大大提高了代码的可重用性。

其次，骨架是自包含的，与筋和皮保持相对独立，所以可以方便的改变应用程序的数据层和业务规则。如果把数据库从MySQL移植到Oracle，或者把RDBMS数据源改变成LDAP数据源，只需改变骨架即可。一旦正确地实现了骨架，不管数据来自数据库还是LDAP服务器，视图都会正确地显示它们。由于筋骨皮模式的三个模块相互独立，改变其中一个不会影响其他两个，所以依据这种设计思想能构造良好的少互扰性的构件。

此外，控制器提高了应用程序的灵活性和可配置性。控制器可以用来连接不同的模型和视图去完成用户的需求，也可以构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择适当的模型机型处理，然后选择适当的的视图将处理结果显示给用户。

缺点及适用范围

筋骨皮模式的缺点是由于它没有明确的定义，所以完全理解筋骨皮模式并不是很容易。使用筋骨皮模式需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。开发一个筋骨皮模式架构的工程，将不得不花费相当可观的时间去考虑如何将筋骨皮模式运用到应用程序中，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。另外由于筋骨皮模式将一个应用程序分成了三个部件，所以这意味着同一个工程将包含比以前更多的文件。

因此筋骨皮模式并不适合小型甚至中等规模的应用程序，这样会带来额外的工作量，增加应用的复杂性。但对于开发存在大量用户界面，并且逻辑复杂的大型应用程序，筋骨皮模式将会使软件在健壮性、代码重用和结构方面上一个新的台阶。尽管在最初构建筋骨皮模式框架时会花费一定的工作量，但从长远的角度来看，它会大大提高后期软件开发的效率。

实现

MFC

微软所推出的MFC Document/View架构是早期对于筋骨皮模式的实现，MFC將程式分成CView以及CDocument兩大類別，其中的Document对应筋骨皮模式中的Model，View相当于筋骨皮模式中的View＋Controller，再加上CWinApp類別，合成三大項。但是基本上MFC是一個失敗的筋骨皮模式作品。

由於MFC之下的Document/View定義過於模糊，未將Controller（MessageMap）部份取出，因此Controller可以置入View或Document，但不管置入哪一方面，都會與View或Document綁死，沒有彈性。

Java

Java 平台企业版 (J2EE)

和其他的各种框架不一样，J2EE为模型对象（Model Objects）定义了一个规范。

视图(View)
在J2EE应用程序中，视图（View）可能由Java Server Page(JSP)承担。生成视图的代码则可能是一个servlet的一部分，特别是在客户端服务端交互的时候。
控制器（Controller）
J2EE应用中，控制器可能是一个servlet，现在一般用Struts实现。
模型（Model）
模型则是由一个实体Bean来实现。

Java Swing

Swing是一个标准的MVC结构. ComponentUI代表View, 负责描画组件. 组件尤其Model层, 比如JTextField的Document, JTable的TableModel, JTree的TreeModel等等. 而Control可能不是很明显, 我们或许可以简单的将其Event机制看作一个Swing团队开发给开发者的Controller.

作为Java开发者, 如果想理解MVC的结构, 学习Swing的确是个不错的选择.

.NET

ASP.NET

在ASP.NET中，针对视图（View）和控制器（Controller）的模式没有被很好地定义。而模型（Model）则留给开发者去设计。

外皮（View视图）
ASPX和ASCX文件被用来处理视图的职责。在这个设计中视图实际上是从控制器继承而来。这个和Smalltalk的实施有所不同，在Smalltalk中不同的类都有指针互相指向对方.
筋（Controller控制器）
控制器的职责被分割成两部分。事件（Event）的产生和传输是框架的一部分，更明确的说是Page和Control两个类。而事件的处理则在分离的代码中实现。
骨架（Model模型）
ASP.NET 不严格需要一个模型。开发者可以自行选择创建一个模型类，但是很多人选择放弃这一步，直接把事件处理放在控制器里处理任何计算、数据保存等等。但用模型来包含商业逻辑和数据存取是可实现的。

ASP.NET MVC

針對原本ASP.NET對於MVC的架構支援的不足，微软官方提供了ASP.NET MVC框架。于2009年3月19日正式发布，新的2.0版本也在测试中。

在新的ASP.NET MVC框架中，表现层与业务逻辑层的关系进一步剥离，但是由于正处于发布初期，因此尚有许多问题没有很好的解决。

Windows Forms

在WinForms中，这个针对视图（View）和控制器（Controller）的模式已经很好的定义好的。而模型（Model）则留给开发者去设计。

外皮（View视图）
由Form或者Control类继承来的一个类处理视图的职责。在WinForm这个例子中视图和控制器被编译在同一个类中，这个和ASP.NET不同。
筋（Controller控制器）
控制器的职责被分割成三部分。事件（Event）的产生和传输是操作系统的一部分。在.Net框架中Form和Control类将不同的事件转发给相应的事件处理器。而事件的处理则在分离的代码中实现。
骨架（Model模型）
就像ASP.NET一样，WinForm不严格需要一个模型。开发者可以自行选择创建一个模型类，但是很多人选择放弃这一步，直接把事件处理放在控制器里处理任何计算、数据保存等等。也就是说用模型来包含商业逻辑和数据存取。

Perl

Catalyst和Jifty是透過Perl語言所開發出來的Web Framework，都採用Model-View-Controller架構。Catalyst 本身只是做了 Controller，View 和 Model 讓開發者自由選用 CPAN 上的模組開發，例如 Template 和 Template Declare 都可用來產生視圖。Jifty 將 MVC 完全實做完成，View 的部份在早期版本使用 Mason 實做，較新版本使用 Template Declare。

Ruby on Rails

Ruby on Rails是透過Ruby語言所開發出來的Web Framework，也是採用Model-View-Controller架構。Model 部份使用 Active Record 概念實做，加上 Migration 機制，使得其 Model 結構非常容易控制。

Python

Python 有許多的 MVC 架構。最常用的有 Django 和 TurboGears。

JavaScript

PHP

ActionScript 3

参考资料

  1. ^ Trygve M. H. Reenskaug/MVC—XEROX PARC 1978-79

外部链接

检索自“https://zh.wikipedia.org/zhwiki/w/index.php?title=MVC&oldid=12842591”