web开发框架-REST VS MVC.docx

1 MVC1.1 定义MVC: 即 MVC框架 。MVC全名是Model View Controller，是模型(model)视图(view)控制器(controller)的缩写，一种软件设计典范。用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。 模型视图控制器（MVC）是Xerox PARC在二十世纪八十年代为编程语言Smalltalk80发明的一种软件设计模式，已被广泛使用。后来被推荐为Oracle旗下Sun公司Java EE平台的设计模式，并且受到越来越多的使用ColdFusion和PHP的开发者的欢迎。模型视图控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点。1.2 分析讨论。1.2.1 MVC 编程模式MVC 是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式： Model（模型）表示应用程序核心（比如数据库记录列表）。 View（视图）显示数据（数据库记录）。 Controller（控制器）处理输入（写入数据库记录）。MVC 模式同时提供了对 HTML、CSS 和 JavaScript 的完全控制。Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。MVC 分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如，您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。MVC 分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑。1.2.2 框架内容MVC是一个框架模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP + servlet + javabean的模式。1.2.3 优点耦合性低视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。模型是自包含的，并且与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。如果把数据库从MySQL移植到Oracle，或者改变基于RDBMS数据源到LDAP，只需改变模型即可。一旦正确的实现了模型，不管数据来自数据库或是LDAP服务器，视图将会正确的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想能构造良好的松耦合的构件。重用性高随着技术的不断进步，需要用越来越多的方式来访问应用程序。MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无需做任何改变。由于已经将数据和业务规则从表示层分开，所以可以最大化的重用代码了。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序所重用。11生命周期成本低MVC使开发和维护用户接口的技术含量降低。部署快使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。可维护性高分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。有利软件工程化管理由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。12-131.2.4 缺点没有明确的定义完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。不适合小型，中等规模的应用程序花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。增加系统结构和实现的复杂性对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。视图与控制器间的过于紧密的连接视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。视图对模型数据的低效率访问依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。一般高级的界面工具或构造器不支持模式改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，会造成MVC使用的困难2 REST2.1 定义REST: 表征状态转移（英文：Representational State Transfer，简称REST）REST是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。目前在三种主流的Web服务实现方案中，因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。例如，A提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。2.2 分析讨论。2.2.1 简介REST表征状态转移。是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。需要注意的是，REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML（标准通用标记语言下的一个子集）以及HTML（标准通用标记语言下的一个应用）这些现有的广泛流行的协议和标准。REST 定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的 Web 服务，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。 如果考虑使用它的 Web 服务的数量，REST 近年来已经成为最主要的 Web 服务设计模式。 事实上，REST 对 Web 的影响非常大，由于其使用相当方便，已经普遍地取代了基于 SOAP 和 WSDL 的接口设计。REST 这个概念于 2000 年由 Roy Fielding（ HTTP规范的主要编写者之一）在就读加州大学欧文分校期间在学术论文“Architectural Styles and the Design of Network-based Software Architectures”首次提出。论文中对使用 Web 服务作为分布式计算平台的一系列软件体系结构原则进行了分析，其中提出的 REST 概念并没有获得太多关注。 今天，REST的主要框架已经开始出现，但仍然在开发中。2.2.2 原则大部分对REST的介绍是以其正式的定义和背景作为开场的。这里提出一个简要的定义：REST定义了Web的使用标准（这和大多数人的实际使用方式有很大不同），例如HTTP和URI。如果你在设计应用程序时能坚持REST原则，那就预示着你将会得到一个使用了优质Web架构（这将让你受益）的系统。REST 并非始终是正确的选择。 它作为一种设计 Web 服务的方法而变得流行，这种方法对专有中间件（例如某个应用程序服务器）的依赖比基于 SOAP 和 WSDL 的方法更少。 在某种意义上，通过强调URI和HTTP等早期 Internet 标准，REST 是对大型应用程序服务器时代之前的 Web 方式的回归。 正如您已经在所谓的基于 REST 的接口设计原则中研究过的一样，XML over HTTP 是一个功能强大的接口，允许内部应用程序（例如基于 Asynchronous JavaScript + XML (Ajax) 的自定义用户界面）轻松连接、定位和使用资源。 事实上，Ajax 与 REST 之间的完美配合已增加了当今人们对 REST 的注意力。通过基于 REST 的 API 公开系统资源是一种灵活的方法，可以为不同种类的应用程序提供以标准方式格式化的数据。 它可以帮助满足集成需求（这对于构建可在其中容易地组合 (Mashup) 数据的系统非常关键），并帮助将基于 REST 的基本服务集扩展或构建为更大的集合。所有资源以ID标识REST中的资源所指的不是数据，而是数据和表现形式的组合。比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是XML（标准通用标记语言下的一个子集）格式、txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。对资源使用一致的命名规则（naming scheme）最主要的好处就是你不需要提出自己的规则而是依靠某个已被定义，在全球范围中几乎完美运行，并且能被绝大多数人所理解的规则。想一下你构建的上一个应用（假设它不是采用RESTful方式构建的）中的任意一个高级对象（high-level object），那就很有可能看到许多从使用唯一标识中受益的用例。比如，如果你的应用中包含一个对顾客的抽象，那么我可以相当肯定，用户会希望将一个指向某个顾客的链接，能通过电子邮件发送到同事那里，或者加入到浏览器的书签中，甚至写到纸上。更透彻地讲：如果在一个类似于Amazon的在线商城中，没有用唯一的ID（一个URI）标识它的每一件商品，可想而知这将是多么可怕的业务决策。当面对这个原则时，许多人惊讶于这是否意味着需要直接向外界暴露数据库记录（或者数据库记录ID）自从多年以来面向对象的实践告诫我们，要将持久化的信息作为实现细节隐藏起来之后，哪怕是刚有点想法都常会使人惊恐。但是这条原则与隐藏实现细节两者之间并没有任何冲突：通常，值得被URI标识的事物资源要比数据库记录抽象的多。例如，一个订单资源可以由订单项、地址以及许多其它方面（可能不希望作为单独标识的资源暴露出来）组成。标识所有值得标识的事物，领会这个观念可以进一步引导你创造出在传统的应用程序设计中不常见的资源：一个流程或者流程步骤、一次销售、一次谈判、一份报价请求这都是应该被标识的事物的示例。同样，这也会导致创建比非RESTful设计更多的持久化实体。下面是一些你可能想到的URI的例子：/customers/1234/orders/2007/10/776654/products/4554/processes/salary-increase-234正如我选择了创建便于阅读的URI这是个有用的观点，尽管不是RESTful设计所必须的应该能十分容易地推测出URI的含义：它们明显地标识着单一“数据项”。但是再往下看：/orders/2007/11/products?color=green首先，这两个URI看起来与之前的稍有不同毕竟，它们不是对一件事物的标识，而是对一类事物集合的标识（假定第一个URI标识了所有在2007年11月份提交的定单，第二个则是绿颜色产品的集合）。但是这些集合自身也是事物（资源），也应该被标识。注意，使用唯一、全局统一的命名规则的好处，既适用于浏览器中的Web应用，也适用于机对机（machine-to-machine，m2m）通信。使用链接指向被标识的资源接下来要讨论的原则有一个有点令人害怕的正式描述：“超媒体被当作应用状态引擎（Hypermedia as the engine of application state）”，有时简写为HATEOAS。严格地说这个描述的核心是超媒体概念，换句话说：是链接的思想。链接是我们在HTML（标准通用标记语言下的一个应用）中常见的概念，但是它的用处绝不局限于此（用于人们网络浏览）。应用程序如何“跟随”链接检索更多的信息。当然，如果使用一个遵守专用命名规范的简单“id”属性作为链接，也是可行的但是仅限于应用环境之内。使用URI表示链接的优雅之处在于，链接可以指向由不同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源因为URI命名规范是全球标准，构成Web的所有资源都可以互联互通。超媒体原则还有一个更重要的方面应用“状态”。简而言之，实际上服务器端（如果你愿意，也可以叫服务提供者）为客户端（服务消费者）提供一组链接，使客户端能通过链接将应用从一个状态改变为另一个状态。对此原则总结如下：任何可能的情况下，使用链接指引可以被标识的资源。使用标准方法在前两个原则的讨论中暗含着一个假设：接收URI的应用程序可以通过URI明确地做一些有意义的事情。如果你在公共汽车上看到一个URI，你可以将它输入浏览器的地址栏中并回车但是你的浏览器如何知道需要对这个URI做些什么呢？它知道如何去处理URI的原因在于所有的资源都支持同样的接口，一套同样的方法（只要你乐意，也可以称为操作）集合。在HTTP中这被叫做动词（verb），除了两个大家熟知的（GET和POST）之外，标准方法集合中还包含PUT、DELETE、HEAD和OPTIONS。这些方法的含义连同行为许诺都一起定义在HTTP规范之中。如果你是一名OO开发人员，就可以想象到RESTful HTTP方案中的所有资源都继承自类似于这样的一个类（采用类Java、C#的伪语法描述，请注意关键的方法）：class Resource Resource(URI u);Response get();Response post(Request r);Response put(Request r);Response delete();由于所有资源使用了同样的接口，你可以依此使用GET方法检索一个表述（representation）也就是对资源的描述。因为规范中定义了GET的语义，所以可以肯定当你调用它的时候不需要对后果负责这就是为什么可以“安全”地调用此方法。GET方法支持非常高效、成熟的缓存，所以在很多情况下，你甚至不需要向服务器发送请求。还可以肯定的是，GET方法具有幂等性译注：指多个相同请求返回相同的结果如果你发送了一个GET请求没有得到结果，你可能不知道原因是请求未能到达目的地，还是响应在反馈的途中丢失了。幂等性保证了你可以简单地再发送一次请求解决问题。幂等性同样适用于PUT（基本的含义是“更新资源数据，如果资源不存在的话，则根据此URI创建一个新的资源”）和DELETE（你完全可以一遍又一遍地操作它，直到得出结论删除不存在的东西没有任何问题）方法。POST方法，通常表示“创建一个新资源”，也能被用于调用任意过程，因而它既不安全也不具有幂等性。如果你采用RESTful的方式暴露应用功能（如果你乐意，也可以称为服务功能），那这条原则和它的约束同样也适用于你。为什么使用标准方法如此重要？从根本上说，它使你的应用成为Web的一部分应用程序为Web变成Internet上最成功的应用所做的贡献，与它添加到Web中的资源数量成比例。采用RESTful方式，一个应用可能会向Web中添加数以百万计的客户URI；如果采用CORBA技术并维持应用的原有设计方式，那它的贡献大抵只是一个“端点（endpoint）”就好比一个非常小的门，仅仅允许有钥匙的人进入其中的资源域。统一接口也使得所有理解HTTP应用协议的组件能与你的应用交互。通用客户程序（generic client）就是从中受益的组件的例子，例如curl、wget、代理、缓存、HTTP服务器、网关还有Google、Yahoo!、MSN等等。总结如下：为使客户端程序能与你的资源相互协作，资源应该正确地实现默认的应用协议（HTTP），也就是使用标准的GET、PUT、POST和DELETE方法。资源多重表述客户程序如何知道该怎样处理检索到的数据，比如作为GET或者POST请求的结果？原因是，HTTP采取的方式是允许数据处理和操作调用之间关系分离的。换句话说，如果客户程序知道如何处理一种特定的数据格式，那就可以与所有提供这种表述格式的资源交互。让我们再用一个例子来阐明这个观点。利用HTTP内容协商（content negotiation），客户程序可以请求一种特定格式的表述：GET /customers/1234 HTTP/1.1Host: Accept: application/vnd.mycompany.customer+xml 请求的结果可能是一些由公司专有的XML（标准通用标记语言下的一个子集）格式表述的客户信息。假设客户程序发送另外一个不同的请求，就如下面这样：GET /customers/1234 HTTP/1.1Host: Accept: text/x-vcard 结果则可能是VCard格式的客户地址。（在这里我没有展示响应的内容，在其HTTP Content-type头中应该包含着关于数据类型的元数据。）这说明为什么理想的情况下，资源表述应该采用标准格式如果客户程序对HTTP应用协议和一组数据格式都有所“了解”，那么它就可以用一种有意义的方式与世界上任意一个RESTful HTTP应用交互。不幸的是，我们不可能拿到所有东西的标准格式，但是，或许我们可以想到在公司或者一些合作伙伴中使用标准格式来营造一个小环境。当然以上情况不仅适用于从服务器端到客户端的数据，反之既然倘若从客户端传来的数据符合应用协议，那么服务器端就可以使用特定的格式处理数据，而不去关心客户端的类型。在实践中，资源多重表述还有着其它重要的好处：如果你为你的资源提供标准通用标记语言下的子集HTML和XML两种表述方式，那这些资源不仅可以被你的应用所用，还可以被任意标准Web浏览器所用也就是说，你的应用信息可以被所有会使用Web的人获取到。资源多重表述还有另外一种使用方式：你可以将应用的Web UI纳入到Web API中毕竟，API的设计通常是由UI可以提供的功能驱动的，而UI也是通过API执行动作的。将这两个任务合二为一带来了令人惊讶的好处，这使得使用者和调用程序都能得到更好的Web接口。 总结：针对不同的需求提供资源多重表述。无状态通信首先，需要着重强调的是，虽然REST包含无状态性（statelessness）的观念，但这并不是说暴露功能的应用不能有状态事实上，在大部分情况下这会导致整个做法没有任何用处。REST要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间（footprint）。（注意，要做到无状态通信往往需要需要一些重新设计不能简单地将一些session状态绑缚在URI上，然后就宣称这个应用是RESTful。）但除此以外，其它方面可能显得更为重要：无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理，可能是软件需要升级重启如果这个客户端访问了从这台服务器接收的链接，它不会察觉到后台的服务器已经改变了。2.2.3 优点REST 与全堆栈 Web 服务根本不同，主要原因有：n REST 的核心抽象是远程资源而不是远程过程调用。n REST采用现有的 Internet 标准，包括 HTTP、XML 和 TCP/IP，而不是另起炉灶，减少学习成本。n REST 没有覆盖每个可能场景，而是覆盖了最常见的问题；不尝试解决所有问题，二十解决大部分常见问题。n 需要降低程序员的复杂度，提高生产效率2.2.4 缺点几年前，Ganesh Prasad问道，Internet比REST更基本吗？这些年，他不断围绕REST SOA、以及更时新的云计算提出相关讨论，并且钟情于REST的指导原则。然而，最近有人在LinkedIn REST架构师讨论组中的一片帖子中问道，“REST的缺点是什么？”Ganesh对此做了回复，然后又在其个人博客中重申了自己的观点：我不能说REST有“缺点”。它说到的都做到了，而且做得很好。但是，请记住REST架构的实现唯一使用的协议是HTTP。我们可以肯定地想象REST在另一种传输协议上的实现，而且其中还包含诸多方面的增强。1. HTTP是一个同步的请求响应式协议。这意味着它不能天然地支持服务端发起的通知（点对点），但这又是经常需要的。这就解释了为什么REST风格的应用程序中的回调需要使用应用层的设计模式，如Webhooks。现在，我们有了WebSockets这样的双向传输协议，也许工业界应该考虑在其之上根据REST原则设计一款新的应用协议。 这一点非常有意思，因为就在差不多一年之前，我们看到有些人甚至在探讨WebSockets和REST是否能够兼容的问题。2. Ganesh认为，REST社区从Web Service协议栈中至少能够学到一些东西：这些协议都是基于核心的SOAP和WS-Addressing消息机制能力之上的端到端的协议。过去，也有人提到过类似的建议。Ganesh接着做了一个类比，他说Web Service之于WS-Addressi