【IT168专稿】我们谈云计算SQL Azure本质，我们可以换一个角度先从设计模式上讲起。设计模式(Design Pattern)的一项重要目的就是“沟通”当人们谈到“歌德式”的设计模式时，脑海里浮现的应该都是一幅很类似的景致，例如：高耸的尖顶建筑、教堂式的外观门庭……，这是建筑师的设计模式。当然它也成功的融入了大众的生活层面，而这才可称为“设计模式”。

　　软件界的设计模式破除了语言的隔阂。Gamma的设计模式(Design Pattern)这个术语是在1990年，由Erich Gamma等人从建筑设计领域引入到软件计算机科学里。该书出版至今，国内软件界在开发应用程序上一直很少运用到设计模式的理论，追根究底的原因很多，沟通应该是其罪魁祸首之一。由我们不容易从字面上感受到这种设计模式的目的或精神，但我们可以经过反复的研读才能体会出来。这种劳民伤财的现象，和设计模式当初被推崇的原则完全不符;所以它在这里也就无从生根，程序设计人员当然也就没有从这里得到太多好处。

　　在这里，我想以声名远播的北京烤鸭是大家再熟悉不过的北京特色了!我们就用“北京烤鸭”来谈谈“一目了然的facade设计模式”。Facad(外观模式)设计模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。它的目的是将杂乱或设计不好的应用程序编程接口(API)再加上一层，把它包起来并提供一个容易看懂的新接口，本因就是提供一个简单的接口，让复杂庞大的程序接口隐藏起来。

　　我们可以借用北京烤鸭作例子，想象一下当你听到“北京烤鸭”时脑中浮现的是甚么呢?一只肉香四溢的烤鸭的全景图吗?若是直觉的、自然的反应那就对了，所以我尝试把facade设计模式直接用一目了然的成语作取代。如图1所示。

　　如上图所示，我们可以举一个façade模式的例子。比如说，现在有一辆汽车，我们(客户程序)要启动它，那我们就要发动引擎(子系统1)，使四个车轮(子系统2)转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。

　　前面说了一堆，读者们一定会想问，到底北京烤鸭跟SQL Azure到底有甚么关系?答案是“目的相同”，也就是考虑到提供使用者一个易读易写的应用程序编程接口。微软的SQL Azure开发团队，正在思考是否应该在云端上就把SQL数据库整个包装起来，再提一个完整而简单的应用程序编程接口给它，藉此让使用者能够轻易上手。

　　另一个选择是考虑到现有程序能够很容易的运用上来的作法，可以让SQL数据库以原本的风貌放置在云端，再透过标准的存取协议让既有的程序都能够立即能使用。这样的抉择也曾不断的出现在一般的IT部门，其立足点是思考是否隐藏那些数据库中的复杂表格信息，用简单易用的API取代，提供程序人员更容易上手的程序环境。今天的SQL Azure正是历经这种选择后的结果，也就是决定采不采用设计模式包装技术在做这个选择的好范例。

　　另外需要考虑，是否提供有效率的读取云端数据的选择。能够快速读写数据库中的数据一直被视为企业信息中心的必备技能，程序设计人员在进入信息单位报到之初，往往都必先从熟悉数据库表开始，也只有在慢慢熟悉数据库表的Layout后才能开始有产能。因此许多信息部门都会为此制订一套数据库的存取应用程序编程接口，然后美其名为“快速数据库存取API”，目的在让程序设计人员能够更简单更轻易的上手。从此，新进人员只要用很短的前置时间来了解这份API就能很快的上手。上面这一段说词，看起来非常合理，也真的有很多人这么做的，但实际上这么做却隐含着一些不好的后遗症。比方说，随着人员及业务种类的增加，一旦应用界面(API)不够用的时候，负责维护的同事就会开始接到报怨及要求;要求新增合用的快速数据库存取API，然后这个API就开始增加，而随着人员及业务种类的增加，API就又得开始增加，这种情形会一直持续的发生一直到你受不了，终于，你提供了一个可以直接传送SQL脚本到数据库上执行的API为止(这跟程序直接呼叫数据库不用透过API，在意义上是完全相同的，因此这个API接口也就名存而实亡)。