Angularjs系列之MVC设计模式

MVC概念

转载时请遵重他人的劳动成果，不要删除作者原文链接。转载请注明来源：http://blog.csdn.net/caoshiying。
谢谢合作。

通过把职责、性质相近的成分归结在一起，不相近的进行隔离，MVC将系统分解为模型、视图、控制器三部分，每一部分都相对独立，职责单一，在实现过程中可以专注于自身的核心逻辑。MVC是对系统复杂性的一种合理的梳理与切分，它的思想实质就是“关注点分离”。

以前的Web编程存在的问题

• CSS和DOM提供的接口水平太低了，而BOM提供的控件只有input、select、textarea这几种最基本的，稍复杂一点的UI效果，都要前端自己利用CSS和DOM去组合创造。看到一个需求，脑子里第一步要想如何利用CSS、DOM这些基本的零件组合成最终的效果，实现最终效果其实是一个“创造”的过程，比如说tabView，treeView，richEditor，colorPicker这种看起来常见的组件，其实在前端里都是没有现成可用的，需要自己去实现。

• 前端语言的胶水性需求太强。CSS、DOM、JS是三种不同的技术，这也是前端知识系统中要掌握的最重要的三个基本功。server端编程当然也会需要不同方向的知识，比如PHP、SQL等，但server端编程大部分时间只用专注在某一个知识点上，只要必要时粘一下其它语言。但前端不同，前端的效果是通过CSS、DOM、JS三者配合起来最终呈现出来的，脱了任何一个技术都寸步难行，时刻要同时考虑多个方向的知识点。换句话说，server端编程像是一个单线程，即使有技术交差，也是串行的，而前端编程像是开了三个线程同时在跑，复杂度是成倍增长的。

• CSS+DOM+JS的组合实在太强大了，同一个效果可以有多种完全不同的实现方式，每一种实现方式都会有不同的开发难度、扩展性、可维护性。解决方案太多，看到一个效果首先会先想到如何用CSS和DOM里那些low level的接口实现，这是一个“创造”的过程，这时脑子里可能冒出好多种不同的实现方法，“创造”完了之后还要“比较”，权衡各种解决方案的优劣，纠结一阵之后，才能选出最适合的方案。当然，并非前端都是完美主义，一定要选一个最好的方式出来，而是因为前端是GUI编程，直接面向用户，是最直接的产品呈现的部分，是门面。正因为如此，所以前端也是最容易被反复修改的部分。反复“修改”有多可怕，是个程序员都懂的，如果可维护性不好，那简直是恶梦。所以前端不得不重视可维护性，不重视可维护性直接等于自虐。

• 浏览器兼容性。浏览器种类非常多，IE、Firefox、Chrome、Opera、还有众多的IE加壳浏览器，类似搜狗、傲游、360，再加上这些浏览器的移动终端版本。需要有Web标准，前端的知识大部分是通用于各个浏览器，但还是会有历史遗留问题，不同的浏览器有不同的问题特别是市场占有率最高的IE系，就IE自己市面上就有6、7、8、9这4个版本，4个版本之间各有各的问题。如果不积累点经验，面对疑难杂症那是一头雾水。

MVC在Web编程中的应用

AngularJS可以通过以下架构与服务器应用程序通讯，把客户端单一的业务角转变为业务与分布式计算单元的复杂角色。

RESTful

REST，Representational State Transfer，中文没有公认的翻译，就字面理解吧。State Transfer 为 “状态传输” 或 “状态转移”，Representational 中文有人翻译为“表征”、“具象”，合起来就是 "表征状态传输" 或 "具象状态传输" 或 "表述性状态转移"它描述了一个架构样式的网络系统，比如 web 应用程序。
REST是一种架构风格，REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。其核心是面向资源，REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。
它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。
REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。您可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。

SOAP

SOAP，英文全拼是Simple Object Access Protocol（1.2版本后停用），中文翻译为简单对象访问协议。它是一个简易对象访问协议，也是一种通信协议，也是一种用于发送消息的格式。它被设计用来通过因特网进行通信，可用于应用程序之间的通信。它基于 XML，独立于平台，独立于语言，允许您绕过防火墙，很简单又可扩展。它将被作为 W3C 标准来发展。
它有四个部分。封装定义了一个框架 , 该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。编码规则定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。RPC表示定义了用于表示远程过程调用和应答的协定。绑定定义了一种使用底层传输协议来完成在节点间交换SOAP封装的约定。一个最简单的表示如下：

<SOAP-ENV:Envelope
　[各种属性]>
<!--百度百科示例-->
　<SOAP:HEADER [各种属性]>
　</SOAP:HEADER>
　<SOAP:Body [各种属性]>
　</SOAP:Body>
</SOAP-ENV:Envelope>

 WSDL

WSDL，Web Services Description Language，Web服务描述语言。在2001年3月，WSDL 1.1被 IBM、微软作为一个W3C记录（W3C note）提交到有关XML协议的W3C XML活动，用于描述网络服务。在2002年7月，W3C 发布了第一个WSDL 1.2工作草案。
WSDL是网络服务描述语言，使用XML编写，是一种XML文档。它用于描述网络服务，也可用于定位网络服务，目前还不是W3C标准，不过W3C网站可以查询它的相关文档。
WSDL元素基于XML语法描述了与服务进行交互的基本元素：

• Type（消息类型）：数据类型定义的容器，它使用某种类型系统（如 XSD）。
• Message（消息）：通信数据的抽象类型化定义，它由一个或者多个 part 组成。
• Part：消息参数
• Operation（操作）：对服务所支持的操作进行抽象描述，WSDL定义了四种操作。
  • 1.单向（one-way）：端点接受信息；
  • 2.请求-响应（request-response）：端点接受消息，然后发送相关消息；
  • 3.要求-响应（solicit-response）：端点发送消息，然后接受相关消息；
  • 4.通知（notification）：端点发送消息。
• Port Type（端口类型）：特定端口类型的具体协议和数据格式规范。
• Binding：特定端口类型的具体协议和数据格式规范。
• Port：定义为绑定和网络地址组合的单个端点。
• Service：相关端口的集合，包括其关联的接口、操作、消息等。

WSDL支持 4 种消息交换方式：

• 单向（One-way）：服务端接收消息；
• 请求响应（Request-response）：服务端点接收请求消息，然后发送响应消息；
• 要求应答（Solicit-response）：服务访问端发送要求消息，然后接收应答消息。
• 通知（Notification）：服务访问端点发送通知消息。

WSDL 文档可以分为两部分。顶部分由抽象定义组成，而底部分则由具体描述组成。抽象部分以独立于平台和语言的方式定义 SOAP 消息，它们并不包含任何随机器或语言而变的元素。这就定义了一系列服务，截然不同的网站都可以实现。随网站而异的东西如序列化便归入底部分，因为它包含具体的定义。

如何架构

这里属于讨论空间。架构方案、技术实现方法千千万，大家自由发挥。我用一点关键词说一下自己的想法。

• 概念：单词缩写，读音
• 架构：业务逻辑层，分布式计算
• 源头：系统跨平台协作方案Web Service
• 依赖注入技术两个体系中的发展：Java开源社区比较活跃的是Spring+Jersey，C#有闭源的原因，除了官方方案，可选余地不多，主要是Autofac+WebAPI
• 云计算：客户端由单一业务单元的角色转变为业务单元与计算节点的复合角色
• 数据交换方案：XML与JSON
• 微软公司：适应技术潮流推行SignalR与WebAPI

转载时请遵重他人的劳动成果，不要删除作者原文链接。转载请注明来源：http://blog.csdn.net/caoshiying。
谢谢合作。

转载于:https://my.oschina.net/zhtqs/blog/1509788