设计模式之我见
设计模式
Design pattern
（
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
设计模式四人帮
设计模式四人组
F（“四人帮”，又称Gang of Four，即Erich Gamma, Richard Helm,Ralph Johnson & John Vlissides四人）的《设计模式》，原名《Design Patterns: Elements of Reusable Object-OrientedSoftware》（1995年出版，出版社：Addison Wesly Longman.Inc），第一次将设计模式提升到理论高度，并将之规范化。该书提出了23种基本设计模式。时至今日，在可复用面向对象软件的发展过程中，新的设计模式仍然不断出现。
设计模式和框架
可复用面向对象软件系统现在一般划分为两大类：应用程序工具箱和框j(Framework)，我们平时开发的具体软件都是应用程序，Java的API属于工具箱；而框架是构成一类特定软件可复用设计的一组相互协作的类，EJB（EnterpriseJavaBeans）是Java应用于企业计算的框架。
框架通常定义了应用体系的整体结构类和对象的关系等等设计参数，以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策，框架强调设计复用，因此框架设计中必然要使用设计模式。
另外，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式，毫无疑问，你将迅速掌握框架的结构，我们一般开发者如果突然接触EJBJ2EE等框架，会觉得特别难学，难掌握，那么转而先掌握设计模式，无疑是给了你剖析EJB或J2EE系统的一把利器。
设计模式的原则
综述
近年来，大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢？这么多设计模式为什么要这么设计呢？说实话，以前我还真没搞清楚。就是看大家一口一个"Design pattern"，心就有点发虚。于是就买了本"四人帮"的设计模式，结果看得似懂非懂:看的时候好像是懂了，过一会就忘了。可能是本人比较"愚钝"吧:))最近，有了点感悟。"独乐不如众乐"，与大家分享一下，还望指教!
为什么要提倡"Design Pattern"呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？OO界有前辈的几个原则："开－闭"原则(Open Closed Principal)、里氏代换原则、合成复用原则。设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。
"开－闭"原则
此原则是由"Bertrand Meyer"提出的。原文是："Software entities shouldbe open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原(是"原"，指原来的代码)代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式"factory pattern":假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一"光盘销售管理软件"。我们应该先设计一"光盘"接口。如图：
[pre]______________
|<>|
| 光盘 |
|_____________|
|+卖() |
| |
|_____________|[/pre]
而盗版盘和毛片是其子类。小子通过"DiscFactory"来管理这些光盘。代码为：
public class DiscFactory{
public static 光盘getDisc(java/lang/String.java.html" target="_blank">Stringname){
return (光盘)java/lang/Class.java.html"target="_blank">Class.forName(name).getInstance();
}
}
有人要买盗版盘，怎么实现呢？
public class 小子{
public static voidmain(java/lang/String.java.html" target="_blank">String[]args){
光盘 d=DiscFactory.getDisc("盗版盘");
d.卖();
}
}
如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个"光盘"的子类"正版软件"就可以了。不需要修改原结构和代码。怎么样？对扩展开放，对修改关闭。"开-闭原则"
工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个"工厂"也进行扩展，那就成了"抽象工厂模式"。
里氏代换原则
里氏代换原则是由"Barbara Liskov"提出的。如果调用的是父类的话，那么换成子类也完全可以运行。比如：
光盘 d=new 盗版盘();
d.卖();
现在要将"盗版盘"类改为"毛片"类，没问题，完全可以运行。Java编译程序会检查程序是否符合里氏代换原则。还记得java继承的一个原则吗？子类override方法的访问权限不能小于父类对应方法的访问权限。比如"光盘"中的方法"卖"访问权限是"public"，那么"盗版盘"和"毛片"中的"卖"方法就不能是protected或private，编译不能通过。为什么要这样呢？你想啊：如果"盗版盘"的"卖"方法是private。那么下面这段代码就不能执行了：
光盘 d=new 盗版盘();
d.卖();
可以说：里氏代换原则是继承复用的一个基础。
合成复用原则
就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。"牵一发而动全身"!面向对象是要把波动限制在尽量小的范围。
在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，"不要与陌生人说话"。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高
理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了"玄冥二老"，所谓"心中无招"。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO之最高境界。呵呵，搞笑，搞笑！（JR）
依赖倒转原则
抽象不应该依赖于细节，细节应当依赖于抽象。
要针对接口编程，而不是针对实现编程。
传递参数，或者在组合聚合关系中，尽量引用层次高的类。
主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉
接口隔离原则
定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干
抽象类
抽象类不会有实例，一般作为父类为子类继承，一般包含这个系的共同属性和方法。
注意：好的继承关系中，只有叶节点是具体类，其他节点应该都是抽象类，也就是说具体类
是不被继承的。将尽可能多的共同代码放到抽象类中。
迪米特法则
最少知识原则。不要和陌生人说话。
编辑本段一个模式的四个基本要素
综述
设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。
模式名称（pattern name）
一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
问题(problem)
描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
解决方案(solution)
描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
效果(consequences)
描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。
编辑本段一些基本的设计模式
综述
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
Adapter：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
Chain of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
Command：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
Composite：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
Decorator：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
Facade：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Factory Method：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
Flyweight：运用共享技术有效地支持大量细粒度的对象。
Interpreter：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。
Iterator：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
Mediator：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Memento：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
Observer：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
Prototype：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Proxy：为其他对象提供一个代理以控制对这个对象的访问。
Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
State：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
Template Method：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
详细描述
从下一节开始，详细描述以下每一种设计模式。
创建型 结构型 行为型
类 Factory Method Adapter_ClassInterpreter
Template Method
对象 Abstract Factory
Builder
Prototype
Singleton Adapter_Object
Bridge
Composite
Decorator
Facade
Flyweight
Proxy Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
概览
Factory Method
结构
意图 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。
适用性 当一个类不知道它所必须创建的对象的类的时候。
当一个类希望由它的子类来指定它所创建的对象的时候。
当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
Abstract Factory
结构
意图 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
适用性 一个系统要独立于它的产品的创建、组合和表示时。
一个系统要由多个产品系列中的一个来配置时。
当你要强调一系列相关的产品对象的设计以便进行联合使用时。
当你提供一个产品类库，而只想显示它们的接口而不是实现时。
Builder
结构
意图 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
适用性 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
当构造过程必须允许被构造的对象有不同的表示时。
Prototype
结构
意图 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
适用性 当要实例化的类是在运行时刻指定时，例如，通过动态装载；或者
为了避免创建一个与产品类层次平行的工厂类层次时；或者
当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
Singleton
结构
意图 保证一个类仅有一个实例，并提供一个访问它的全局访问点。
适用性 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。
Adapter
结构
意图 将一个类的接口转换成客户希望的另外一个接口。A d a p t e r 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
适用性 你想使用一个已经存在的类，而它的接口不符合你的需求。
你想创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类（即那些接口可能不一定兼容的类）协同工作。
（仅适用于对象A d a p t e r ）你想使用一些已经存在的子类，但是不可能对每一个都进行子类化以匹配它们的接口。对象适配器可以适配它的父类接口。
Bridge
结构
意图 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
适用性 你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。
类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时B r i d g e 模式使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。
对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。
（C + +）你想对客户完全隐藏抽象的实现部分。在C + +中，类的表示在类接口中是可见的。
有许多类要生成。这样一种类层次结构说明你必须将一个对象分解成两个部分。R u m b a u g h 称这种类层次结构为“嵌套的普化”（nested generalizations ）。
你想在多个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一点。一个简单的例子便是C o p l i e n 的S t r i n g 类[ C o p 9 2 ]，在这个类中多个对象可以共享同一个字符串表示（S t r i n g R e p ）。
Composite
结构
意图 将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e 使得用户对单个对象和组合对象的使用具有一致性。
适用性 你想表示对象的部分-整体层次结构。
你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
Decorator
结构
意图 动态地给一个对象添加一些额外的职责。就增加功能来说，D e c o r a t o r 模式相比生成子类更为灵活。
适用性 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
处理那些可以撤消的职责。
当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
Facade
结构
意图 为子系统中的一组接口提供一个一致的界面，F a c a d e 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用性 当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来一些使用上的困难。F a c a d e 可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过f a c a d e 层。
客户程序与抽象类的实现部分之间存在着很大的依赖性。引入f a c a d e 将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
当你需要构建一个层次结构的子系统时，使用f a c a d e 模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过f a c a d e 进行通讯，从而简化了它们之间的依赖关系。
Flyweight
结构
意图 运用共享技术有效地支持大量细粒度的对象。
适用性 一个应用程序使用了大量的对象。
完全由于使用大量的对象，造成很大的存储开销。
对象的大多数状态都可变为外部状态。
如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。
应用程序不依赖于对象标识。由于F l y w e i g h t 对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。
Proxy
结构
意图 为其他对象提供一种代理以控制对这个对象的访问。
适用性 在需要用比较通用和复杂的对象指针代替简单的指针的时候，使用P r o x y 模式。下面是一些可以使用P r o x y 模式常见情况：
1) 远程代理（Remote Proxy ）为一个对象在不同的地址空间提供局部代表。 NEXTSTEP[Add94] 使用N X P r o x y 类实现了这一目的。Coplien[Cop92] 称这种代理为“大使” （A m b a s s a d o r ）。
2 )虚代理（Virtual Proxy ）根据需要创建开销很大的对象。在动机一节描述的I m a g e P r o x y 就是这样一种代理的例子。
3) 保护代理（Protection Proxy ）控制对原始对象的访问。保护代理用于对象应该有不同 的访问权限的时候。例如，在C h o i c e s 操作系统[C I R M 9 3 ]中K e m e l P r o x i e s 为操作系统对象提供 了访问保护。
4 )智能指引（Smart Reference ）取代了简单的指针，它在访问对象时执行一些附加操作。 它的典型用途包括：
对指向实际对象的引用计数，这样当该对象没有引用时，可以自动释放它(也称为S m a r tP o i n t e r s[ E d e9 2 ] )。
当第一次引用一个持久对象时，将它装入内存。
在访问一个实际对象前，检查是否已经锁定了它，以确保其他对象不能改变它。
Chain of Responsibility
结构
意图 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用性 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
可处理一个请求的对象集合应被动态指定。
Command
结构
意图 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
适用性 像上面讨论的Me n u I t e m 对象那样，抽象出待执行的动作以参数化某对象。你可用过程语言中的回调（c a l l b a c k ）函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。C o m m a n d 模式是回调机制的一个面向对象的替代品。
在不同的时刻指定、排列和执行请求。一个C o m m a n d 对象可以有一个与初始请求无关的生存期。如果一个请求的接收者可用一种与地址空间无关的方式表达，那么就可将负责该请求的命令对象传送给另一个不同的进程并在那儿实现该请求。
支持取消操作。C o m m a n d 的E x c u t e 操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。C o m m a n d 接口必须添加一个U n e x e c u t e 操作，该操作取消上一次E x e c u t e 调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用U n e x e c u t e 和E x e c u t e 来实现重数不限的“取消”和“重做”。
支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在C o m m a n d 接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用E x e c u t e 操作重新执行它们。
用构建在原语操作上的高层操作构造一个系统。这样一种结构在支持事务( t r a n s a c t i o n )的信息系统中很常见。一个事务封装了对数据的一组变动。C o m m a n d 模式提供了对事务进行建模的方法。C o m m a n d 有一个公共的接口，使得你可以用同一种方式调用所有的事务。同时使用该模式也易于添加新事务以扩展系统。
Interpreter
结构
意图 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
适用性 当有一个语言需要解释执行,并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：
该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。
效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。
Iterator
结构
意图 提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。
适用性 访问一个聚合对象的内容而无需暴露它的内部表示。
支持对聚合对象的多种遍历。
为遍历不同的聚合结构提供一个统一的接口(即, 支持多态迭代)。
Mediator
结构
意图 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
适用性 一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。
想定制一个分布在多个类中的行为，而又不想生成太多的子类。
Memento
结构
意图 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
适用性 必须保存一个对象在某一个时刻的(部分)状态, 这样以后需要时它才能恢复到先前的状态。
如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。
Observer
结构
意图 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
适用性 当一个抽象模型有两个方面,其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。
State
结构
意图 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
适用性 一个对象的行为取决于它的状态, 并且它必须在运行时刻根据状态改变它的行为。
一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。这个状态通常用一个或多个枚举常量表示。通常, 有多个操作包含这一相同的条件结构。S t a t e模式将每一个条件分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。
Strategy
结构
意图 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
适用性 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。
需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时[ H O 8 7 ] ,可以使用策略模式。
算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的S t r a t e g y 类中以代替这些条件语句。
Template Method
结构
意图 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Te m p l a t e M e t h o d 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
适用性 一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现。
各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复。这是O p d y k e 和J o h n s o n 所描述过的“重分解以一般化”的一个很好的例子[ O J 9 3 ]。首先识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
控制子类扩展。模板方法只在特定点调用“h o o k ”操作（参见效果一节），这样就只允许在这些点进行扩展。
Visitor
结构
意图 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
适用性 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Vi s i t o r 使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Vi s i t o r 模式让每个应用仅包含需要用到的操作。
定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。
编辑本段成功采用设计模式的步骤
综述
如何把设计模式的采用和日益临近的最后期限、紧缩的预算和很多公司现有的有限团队资源相结合？以下是成功制订设计模式的步骤。
强大的通信和培训
许多机构拥有领先技术，可能正式通过了设计师论坛的论证或者非正式的公认专家。这些领先厂商将推广设计模式采用中的开放通信，并将培训开发具体设计模式的团队。通信应当跨开发团队和项目以便预先防止采用竖井和多种惟一的实现（谨记每个Developer/Project AntiPattern的实现）。培训可以采用正式的internal lunch-and-learns、正式的internal class或者派一些员工参加外部培训。这些培训方式将促进正确的设计模式应用程序。如果仅有极少的观众能够参加培训，最佳的候选人是那些感觉适合在回来后能够培训其同事的人。
设计模式采用指导
设计模式可用于使项目受益，但是他们也可能因为误用而对应用程序造成损害。应当鼓励采用他们，但是对其的采用应当受到审阅和验证。设计模式可以包含在设计和开发过程中。在任何一种情况中，设计模式的使用应当由审阅者确认和验证。在审阅过程中还可能会遇到这样的情况，额外的设计模式不适用于最初包括的地方。即使环境中没有进行正式的审阅，这一步骤也可以通过同事审阅或者团队讨论来完成。这一步骤中的审阅者要么是主要团队的成员，要么与他们建立开放通信。
指导采用对于broad exposure类别的设计模式非常关键。这些设计模式具有很多相关的风险，因为他们将创建依赖性。这些依赖性可能在一些对象类中，例如，只工作在更加广泛的DAO设计模式实现范围中的数据访问对象（DAO）、或者跨应用程序边界（如使用Value Object设计模式在应用程序和应用程序层之间传输数据）。这些设计模式也可以由项目中的其他人或者不同项目的人实现，而且实现应当重新使用，不同于创建另一种独特的实现。
重用实现,不只是设计模式
只要在创建自己的设计模式实现中有一定的满足，团队和公司就可以在重用发生在代码层时，而不是设计创意层时获得更多益处。使企业获益的最初设计模式是改进的实现。但是，真正的目标是重用实现。重用实现将导致：a)其他可重用的类（取决于公共实现）；b)缩短开发时间和降低成本；c)缩短维护时间和降低成本；d)在应用程序之间和内部轻松集成。
这种重用对broad exposure设计模式非常重要（有时是基本的）。这些设计模式创建了外部依赖性（集成将从公共实现中受益）或者产生全部的自定义类库（如果有公共基础将可重用）。isolated use设计模式也可以从重用中获益，但是如果他们是根据具体情况定制的，他们就非常难以重用。
有时您可能会问自己：“如果重用比较好，为什么设计模式和可以重用的实现不可以一同应用呢？”在我们讨论设计模式如何使更多读者获益的时候才会讨论这个问题。如果可能，如果已经预定义了实现，那么达到广泛适用性这个目标就会非常困难。然而，一旦设计模式被应用到特殊的问题域或者技术基础设施中，那么就可以重用在该环境中产生的实现。
架构中的设计模式
这看起来像是一件可怕的任务，需要掌握设计模式如何应用在实际情况中，如何构建优质的实现，以及如何促进重用实现。完成该任务的方法之一就是在环境中引入应用程序架构。应用程序架构提供了应用程序需要的结构，从而使开发团队可以关注应用程序的域逻辑。这包含了已实现的设计模式。除了重用设计模式概念或者单个实现之外，可以在多个项目和应用程序之间重用架构。这种共享的公共实现确保了兼容性，并为开发和维护多种不同的实现提供了一种低成本替代方案。兼容性提供了重新使用需要的技术基础。没有足够的篇幅在这里深入讨论架构的其他重要品质，如运行时监测和管理、可配置应用程序逻辑和适应性行为等。您可以从Carnegie Mellon SoftwareEngineering Institute 中学习到更多有关架构的知识。
编辑本段设计模式的形象比喻
1、ABSTRACT FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory
工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞定，这就是我的“我爱你 ”builder。（这一定比美军在伊拉克用的翻译机好卖）
建造模式：将对象的内部表象和对象的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）
原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。
5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)
单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。
6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)
适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。
7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。
8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻烦你包起来。 ”“……”，MM都会用Composite模式了，你会了没有？
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？
装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。
10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。
享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。
12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。
代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象必须有系统的其他角色代为创建并传入。
13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!
责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。”
命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。
15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。
解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。
Mary：“想要我跟你结婚，得答应我的条件”
我：“什么条件我都答应，你说吧”
Mary：“我看上了那个一克拉的钻石”
我：“我买，我买，还有吗？”
Mary：“我看上了湖边的那栋别墅”
我：“我买，我买，还有吗？”
Mary：“我看上那辆法拉利跑车”
我脑袋嗡的一声，坐在椅子上，一咬牙：“我买，我买，还有吗？”
迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。
17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。
调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。
18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。
备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。
19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦
观察者模式：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上去看电影，对你没兴趣的MM就会说 “有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。
状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。
21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。
策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。
22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；
模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。
23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板也根据每个人特点选一张卡，这样就轻松多了；
访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
）
（
式设计是思维具体化的一种方式，是思考如何解决问题的过程，设计模式是在解 决问题的过程中，一些良好思路的经验集成，最早讲设计模式，人们总会提到Gof 的著作，它最早将经典的 23 种模式集合在一起说明，对后期学习程式设计，尤其是对从事物件导向程式设计的人们起了莫大的影响。
后来设计模式一词被广泛的应用到各种经验集成，甚至还有反模式（AntiPattern），反模式教导您如何避开一些常犯且似是而非的程式设计思维。
这边的话将整理一些设计模式学习心得，实作的部份是使用Java，因而您会看到一些与 Gof 模式不同的图及实作方式，这是为了善用一些Java本身的特性，至于C++的实作方面，Gof 的书已经给了不少的例子。
在一些模式的实作上，您会发现我用了介面（interface）来取代抽象类别（Abstract class），这与原先的Gof书中的范例会不尽相同，这是因为在C++中没有介面，一个完全没有实作任何方法的抽象类别，根据当时描述的主题特性，可以 的话会将之换为介面，在语义上会较符合Java语言的特性，但是您要知道的是，介面与完全没有实作任何方法的抽象类别在某些时候是可以互换的。
在这边所看到的 UML 图都是使用 Jude 绘制的，Jude 是一个纯 Java 撰写的 UML 工具程式，可运行与 Windows、Linux 等多个平台，体积小，使用简易。
Gof 模式
以下的设计模式则是我个人从 Gof 学习中的个人体会与实作，并增加几个导入或衍生的简单模式。
- Creational 模式
物件的产生需要消耗系统资源，所以如何有效率的产生、管理 与操作物件，一直都是值得讨论的课题，Creational 模式即与物件的建立相关，在这个分类下的模式给出了一些指导原则及设计的方向。
- Simple Factory 模式
- Abstract Factory 模式
- Builder 模式
- Factory Method 模式
- Prototype 模式
- Singleton 模式
- Registry of Singleton 模式
- Structural 模式
如何设计物件之间的静态结构，如何完成物件之间的继承、实 现与依赖关系，这关乎着系统设计出来是否健壮（robust）：像是易懂、易维护、易修改、耦合度低等等议题。Structural模式正如其名，其分类下的模式给出了在不同场合下所适用的各种物件关系结构。
- Default Adapter 模式
- Adapter 模式 - Object Adapter
- Adapter 模式 - Class Adapter
- Bridge 模式
- Composite 模式
- Decorator 模式
- Facade 模式
- Flyweight 模式
- Proxy 模式（一）
- Proxy 模式（二）
- Behavioral 模式
物件之间的合作行为构成了程式最终的行为，物件之间若有设 计良好的行为互动，不仅使得程式执行时更有效率，更可以让物件的职责更为清晰、整个程式的动态结构（像是物件调度）更有弹性。
- Chain of Responsibility 模式
- Command 模式
- Interpreter 模式
- Iterator 模式
- Mediator 模式
- Memento 模式
- Observer 模式
- State 模式
- Strategy 模式
- Template Method 模式
- Visitor 模式
多执行绪模式
在很多应用中都会使用多执行绪，尤其是在Web应用中，多执行绪以 Gof 整理的模式为基础，考量多执行绪环境中，如何组合这些基本模式来完成多执行绪安全要求。
- Guarded Suspension 模式
- Producer Consumer 模式
- Worker Thread 模式
- Thread-Per-Message 模式
- Future 模式
- Read-Write-Lock 模式
- Two-phase Termination 模式
- Thread-Specific Storage 模式
参考资料
以下是以Java实作设计模式的介绍网站，从下面的连结开始，当中您可以找到更多设计模式的资源。
- Huston Design Pattern
- The Design Patterns Java Companion
- 板 桥里人的 Java 设计模式学习心得
- UML 软件工程组织
）
原型模式
Builder
Singleton
Façade(外观模式)
Factory()
Adapter
观察者模式
设计模式思想的应用
2.1设计模式思想概述
设计模式思想引入企业级数据库系统开发，与传统的开发模式可谓是一场革命.设计模式之于面向对象的设计与开发的作用就有如数据结构之于面向过程开发的作用一般，其重要性不言而喻。当然学习设计模式的过程也是痛苦的，对于GoF的23种设计模式要一一学懂它，无疑是非常痛苦的。
面向对象系统的设计与分析实际上就是追求的两点：一是高内聚，一是低耦合。这也是我们软件设计所要追求的，无论是ＯＯ设计中的封装、继承、多态，还是我们的设计模式的原则和实例，都是主要为了追求这两点。有人说，我们的系统小，使用设计模式会束缚我们的实现，其实不然，就如K_Eckel在他所写的《设计模式精解》一书中提到的：设计模式体现的是一种思想，而思想是指导行为的一切，理解和掌握了设计模式，并不是说记住GoF的23种设计模式的设计场景以及解决方案，而实际接受的是一种软件设计思想的熏陶和洗礼，等设计模式的思想真正融入到你的思想中后，你就会不自觉得去采用设计模式的思想去设计你的系统，这才是最重要的。因此我并不想重复地去讲述这23种设计模式，更不会拘泥于其中的任何一种，我只是根据我的经验和对设计模式的思想的理解，来实现我的业务逻辑层的设计。
我们在面向对象的设计中常常会遇到一些问题，比如说为了提高程序的高内聚低耦合，我们通常会抽象出一些类的公共接口以形成抽象基类，这样我们可以为它派生很多个子类,通过申明一个抽象基类的但被实例化为指向派生类的对象，以达到多态的目的。然而当业务复杂并产生了大量的派生类时，程序员就得记住每一个派生类的名字然后New出一个指向它的指针。这就给编写程序和维护代码带来了很大的困难，这种情况下我们如果要求客户端传入一个名称，我们用一个switch根据传入的名称来New一个子类，这就实现了中间层的封装。还有比如我的一个数据库系统中，有几百个表/视图等对象，要对它们进行访问，如果只用面向对象的思想去操作它们，我们需要把这些数据库对象都抽象为类，封装它们自己的属性和方法，这样的工作量无疑是非常巨大的。于是我利用设计模式的思想动态地分类抽象它们，也就是说，在访问它们之前，才产生具有实体意义的类。我们可以将几十个、几百个属性、方法类同的数据库表做成一个Template Class,这样的封装方式使得代码量减少到原来的几十甚至几百分之一，而且它最大的好处是脱离了数据库… …等等在面向对象设计中出现的问题我们大都可以用设计模式的思想去解决它，就如我们在c程序中遇到一些比较麻烦的功能时，就会想到用数据结构中的一些算法去解决它一样。
2.2数据库应用中设计模式的抽象
说了这么多，我就举一个例子来说明如何在三层架构部署的企业级数据库应用系统中如何使用设计模式：
数据库系统中我们最关心的就是如何操作数据库中的那些对象，我们可以将数据库中的对象看作是用来生产某一种产品的模具，每一种类型的对象就是一种模具,比如表、视图、存储过程，我们可以将它们当作是三种模具，当然你可以根据业务及数据库化分的更细一点，比如单表模具，主从表模具，视图模具、存储过程模具、数据库函数模具等等，不够的你可以去继续扩展;假使我们现在有一个工厂,它有好多个车间，每个车间只能够使用一种模具来生产产品,我们可以分别给它们起名字叫表车间、视图车间、存储过程车间等。当用户想要往USER表中插入一条记录的时候，我们可以说成是在工厂要在表车间使用表模具生产出一个叫做USER的产品,然后产品进行加工的过程。那生产并加工这个产品过程到底是怎么样的呢？这里我说明一下工厂、车间、模具、产品它们各自的功能以及在一个产品在产生和加工过程中所处的环节，事实上根据它们的名字也不难理解。
工厂：它要存贮下所有的产品名和车间名以及产品名与车间的多对一关系，用户需要知道自己要生产的产品名字是什么，工厂根据产品名来判断送交给哪个车间去处理.
车间：车间使用它拥有的模具来产生一个具体产品
模具：模具产生一个产品对象
产品：进行自加工(插入、删除、修改、查询等)
那么，现在我们来看看当用户通过界面层的交互，想对表USER插入一条记录的过程：事实上用户并不知道它现在操作表叫做USER,而界面层上的对象则必须知道当前操作界面所对应数据库表的名字，有了这个已知条件,界面层调用业务接口层的提供的获取表信息函数接口【例如：DataSetGetTabInfo(string _tabname）;//得到当前表的信息】，接口产生一个工厂，工厂就判断这个USER属于哪个车间生产，将USER转交给表车间，表车间产生一个表模具对象，并生产出一个名叫USER的产品对象,产品对象调用自己的获取信息函数【例如：DataSetGetTabInfo(string _tabname）;//得到当前表的信息，并记录到产品对象属性中,实际上这个GetTabInfo过程调用了数据访问层提供的花取字段信息接口】,对本身做了一次加工，也就是说此时USER这个产品已经拥有了USER表的信息(字段、主键等),然后返回到业务接口层，业务接口层将这个具体的USER产品返回给界面层，界面层得到产品后，将数据填充到产品的属性(行和列)中，实际上就是增加一行给字段赋值的过程,然后再调用业务接口提供的插入数据接口【例如:InsertData(DataSet_tabinfo);】,同样的，接口产生工厂，工厂找到车间，重新构造产品，产品对象对本身做插入操作,返回。这就是一个完整的操作过程。
当我真正地了解了GoF的《设计模式：可复用面向对象软件的基础》中的思想后，我突然发现真正如K_Eckel所说，经过了一场软件设计思想的洗礼，做系统设计时的思想发生了质的变化，封装、复用、多态、抽象……
3.三层架构与设计模式在Web应用系统中的应用
3.1用c#描述系统架构设计
3.1.1在.net中创建工程
1) 首先打开Microsoft VisualStdio .Net 2003,新建一个C#项目asp.net Web应用程序，如图2所示:
图2
2) 在新生成的解决方案中加入以下类库：
GlobalDataTypeLayer:公用参数层
BusinessLayer:业务逻辑层（可以将里面的四层全部分开，建成类库）
DataAccessLayer:数据访问层，为了更好的扩展，我在代码表现形式上只将该层从业务逻辑层分离出来
界面规则层可直接置于asp.net项目中，因为它是界面外观层的基类，在一个命名空间中使用比较方便。各层之间互相的引用联系是这样的，首先要将GlobalDataTypeLayer命名空间在其它各层全部引用，UserRoleLayer命名空间中再引用BusinessLayer,BusinessLayer再引用DataAccessLayer。引用事例图如图3所示:
图3
3.1.2应用于系统层次结构调用过程以及类的代码实现
3.1.2.1界面表示层类图(如图4)
图4
图2展示的是用户界面表示层的类图结构，图中显示了共三个类，WebForm Class与PrintControl Class都属于界面外观层。
WebForm Class这不仅仅表示一个类，而表示一批类，因为一般情况下与用户交流的类的属性及操作都大同小异，我们可以从一个基类中派生，以便于编程和管理。当然如果有一些类差别比较大，可以重新概造相应的基类，重新派生，界面层的扩展可以很灵活地通过增加基类来实现。
PrintControl Class : 打印控制类，主要以客户端脚本来实现，不与服务器进行数据交互，打印预览之前，打印数据应由WebForm类提交给PrintControl。
PageBase Class 这个类属于界面规则层，它是WebForm的基类，事实上界面外观与界面规则可以放在一个命名空间中，它可以是一个类，也可以是多个类，业务的复杂程度也决定了PageBase Class的扩展，根据不同的需求可以构造相应的WebForm基类来满足业务需求。
3.1.2.2业务逻辑层类图(如图5)
图5
图5展示了复杂的业务逻辑层调用过程,其中主要展示的类有六个类，不包含派生的子类。
ParamData Class 公用参数类，这个类事实上并不属于三层架构中的任何层，我单独将其定义为公用参数层，它与三层架构中的任何一个类都息息相关,实现代码见附录A
InterfaceImpl Class 是业务逻辑层向界面表示层提供的接口类，数据由界面规则层封装传入，对外接口函数根据业务需求可以增加。该类的所有函数实现基本都很类似，ClassBuilderFactoryClass 工厂类，它的作用是根据接口类传入的数据找到对应的生产构造部件(ClassBuilder),这里很重要的是包含了一个简单的map，该结构在连接数据库里进行实例化，ClassBuilder Class 这是构造部件的抽象基类，其下可以根据业务的需求扩展很多的构件器，可以用工厂的模式理解其为构件车间，我这里派生的构件器有：
TableClassBuilder:实体表构件器
ViewClassBuilder:视图构件器
ProcedureClassBuilder:存储过程构件器
OtherClassBuilder:其它构件器
EntityData Class 这是实体类的抽象基类，其下也可以根据业务的需求扩展派生实体，前面我提到过我们的构件器与实体类是一一对应的，一个构件车间只能够生产一类产品。那么对应的派生实体就有：
TableEntityData:表实体
ViewEntityData:视图实体
ProcedureEntityData:存储过程实体
OtherClassEntityData:其它实体(这个实体的自我加工可以灵活定义)
DataAccess Class 是数据访问层的数据访问类，这里才真正实现了数据库连接，数据库读写等，将用户的数据构造成sql语句与数据库交互。如果想在整个系统中兼容各种数据库，那么可以将它抽象为数据访问的抽象基类，可以去派生OracleDataAccess,SqlServerDataAccess,AccessDataAccess等等，它们的属性和方法基本上都是相同的，只是具体方法中的实现有所不同而已，访问Oracle部分实例代码见附录A。
在实例化并填充工厂MAP的时候用XML存储构件的产品名与产品类型名的多对一关系，XML结构见附录
3.1.2.3 数据库层
数据库层指的主要是系统采用的数据库管理系统(DBMS),在整套企业级数据库应用系统中，它是最重要的一环，其中主要的对象有表、视图、存储过程、函数、触发器等，数据的许多处理都应该由数据库本身去完成，例如将复杂的查询或者数据写入，都封装为存储过程和函数，将数据写入前后要进行的附加操作用触发器实现等等。对于表的创建一般应以数据库原理的第三范式规范来创建,允许一定的冗余。表及视图的创建规范直接影响到代码编写的难易度。
到这里，关于三层架构与设计模式思想部署企业级数据库应用系统开发应趋于完整了，我想主要向大家展示的实际上就是一种程序设计的思想，不管是三层架构还是设计模式，它们都是软件工程面向对象思想的完全体现，目前，我们国家软件业相对来说是很落后的，关键的问题是软件企业的急功近利和程序员思想还停留在结构化思想上，不能说你在程序中用的是类就说你的思想是面向对象，也不是说你会使用java编写程序，就说自己懂得面向对象，希望我和大家能一起进步，直正理解面向对象。
引言：本文不是从理论的角度来探讨三层架构，而是用一个示例来介绍如何建设一个三层架构的项目，并说明项目中各个文件所处的层次与作用。写本文的目的，不是为了说明自己的这个方法有多对，别人的肯定不对，而是希望给那些初学三层架构却不知从何入手的朋友提供一点帮助。因为网上的文章，大多是注重理论的介绍，而忽略了具体的实践应用，或者有示例但讲得不透彻。导致看了之后，理论上又学习了一遍，但还是不知道代码怎么写。所以想从这个方面入手写一下，让从来没做过三层架构的初学者也能照猫画虎，写出代码来。文章表述的是笔者个人对三层架构的认识，肯定有许多不足的地方，欢迎大家指正，小弟也会根据反馈来修改这篇文章。文中的代码是伪代码，仅用来阐明思路。
正文：
一提三层架构，大家都知道是表现层（UI），业务逻辑层（BLL）和数据访问层（DAL），而且每层如何细分也都有很多的方法。但具体代码怎么写，到底那些文件算在哪一层，却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目，这个例子只有一个功能，就是用户的简单管理。
首先建立一个空白解决方案，添加如下项目及文件
1、添加ASP.NET Web Application项目，命名为UI，新建Web Form类型文件User.aspx（含User.aspx.cs）
2、添加ClassLibrary项目，命名为BLL，新建Class类型文件UserBLL.cs
3、添加ClassLibrary项目，命名为DAL，新建Class类型文件UserDAL.cs。添加SQLHelper引用。（这个是微软的数据访问类，也可以不用，直接编写所有的数据访问代码。我一般用自己写的数据访问类DataAccessHelper ）。
4、添加ClassLibrary项目，命名为Model，新建Class类型文件UserModel.cs
5、添加ClassLibrary项目，命名为IDAL，新建Interface类型文件IUserDAL.cs
6、添加ClassLibrary项目，命名为ClassFactory
相信大家已经看出来了，这个和Petshop的示例没什么区别，而且更简单，因为在下也是通过Petshop学习三层架构的。但一些朋友对于这几个项目所处的层次，以及它们之间的关系，可能比较模糊，这里逐个说明一下：
1、User.aspx和User.aspx.cs
这两个文件（以及文件所属的项目，下面也是如此，不再重复强调了）都属于表现层部分。User.aspx比较好理解，因为它就是显示页面了。User.aspx.cs有些人觉得不应该算，而是要划到业务逻辑层中去。如果不做分层的话，那么让User.aspx.cs来处理业务逻辑，甚至操作数据库都没什么问题，但是做分层的话，这样就不应该了。在分层结构中，User.aspx.cs仅应该处理与显示有关的内容，其它部分都不应该涉及。
举例：我们实现用列表方式显示用户的功能，那么提取信息的工作是由BLL来做的，UI（本例中是User.aspx.cs）调用BLL得到UserInfo后，通过代码绑定到User.aspx的数据控件上，就实现了列表的显示。在此过程中User.aspx.cs对UI没有起到什么作用，仅是用来传递数据，而且因为实际编码中大部分情况都是如此的实现，所以使有些人觉得User.aspx.cs不应该算UI，而应该并入BLL负责逻辑处理。继续往下看，这时提出了一个新需求，要求在每个用户的前面加一个图标，生动地表现出用户的性别，而且不满18岁的用儿童图标表示。这个需求的实现，就轮到User.aspx.cs来做了，这种情况下User.aspx.cs才算有了真正的用途。
2、NewBLL.cs
添加如下方法：
public IList<UserInfo> GetUsers()：返回所有的用户信息列表
public UserInfo GetUser(int UserId)：返回指定用户的详细信息
public bool AddUser(UserInfo User)：新增用户信息
public bool ChangeUser(UserInfo User)：更新用户信息
public void RemoveUser(int UserId)：移除用户信息
此文件就属于业务逻辑层了，专门用来处理与业务逻辑有关的操作。可能有很多人觉得这一层唯一的用途，就是把表现层传过来的数据转发给数据层。这种情况确实很多，但这只能说明项目比较简单，或者项目本身与业务的关系结合的不紧密（比如当前比较流行的MIS），所以造成业务层无事可做，只起到了一个转发的作用。但这不代表业务层可有可无，随着项目的增大，或者业务关系比较多，业务层就会体现出它的作用来了。
此处最可能造成错误的，就是把数据操作代码划在了业务逻辑层，而把数据库作为了数据访问层。
举例：有些朋友感觉BLL层意义不大，只是将DAL的数据提上来就转发给了UI，而未作任何处理。看一下这个例子
BLL层
SelectUser（UserInfo userInfo）根据传入的username或email得到用户详细信息。
IsExist（UserInfo userInfo）判断指定的username或email是否存在。
然后DAL也相应提供方法共BLL调用
SelectUser（UserInfo userInfo）
IsExist（UserInfo userInfo）
这样BLL确实只起到了一个传递的作用。
但如果这样做：
BLL.IsExist（Userinfo userinfo）
{
UerInfouser = DAL.SelectUser（User）；
return (userInfo.Id != null);
}
那么DAL就无需实现IsExist()方法了，BLL中也就有了逻辑处理的代码。
3、UserModel.cs
实体类，这个东西，大家可能觉得不好分层。包括我以前在内，是这样理解的：UIßàModelßàBLLßàModelßàDAL，如此则认为Model在各层之间起到了一个数据传输的桥梁作用。不过在这里，我们不是把事情想简单，而是想复杂了。
Model是什么？它什么也不是！它在三层架构中是可有可无的。它其实就是面向对象编程中最基本的东西：类。一个桌子是一个类，一条新闻也是一个类，int、string、doublie等也是类，它仅仅是一个类而已。
这样，Model在三层架构中的位置，和int，string等变量的地位就一样了，没有其它的目的，仅用于数据的存储而已，只不过它存储的是复杂的数据。所以如果你的项目中对象都非常简单，那么不用Model而直接传递多个参数也能做成三层架构。
那为什么还要有Model呢，它的好处是什么呢。下面是思考一个问题时想到的，插在这里：
Model在各层参数传递时到底能起到做大的作用？
在各层间传递参数时，可以这样：
AddUser（userId，userName，userPassword，…，）
也可以这样：
AddUser（userInfo）
这两种方法那个好呢。一目了然，肯定是第二种要好很多。
什么时候用普通变量类型（int,string,guid,double）在各层之间传递参数，什么使用Model传递？下面几个方法：
SelectUser（int UserId）
SelectUserByName（string username）
SelectUserByName（string username，string password）
SelectUserByEmail（string email）
SelectUserByEmail（string email，string password）
可以概括为：
SelectUser（userId）
SelectUser（user）
这里用user这个Model对象囊括了username，password，email这三个参数的四种组合模式。UserId其实也可以合并到user中，但项目中其它BLL都实现了带有id参数的接口，所以这里也保留这一项。
传入了userInfo，那如何处理呢，这个就需要按照先后的顺序了，有具体代码决定。
这里按这个顺序处理
首先看是否同时具有username和password，然后看是否同时具有email和password，然后看是否有username，然后看是否有email。依次处理。
这样，如果以后增加一个新内容，会员卡（number），则无需更改接口，只要在DAL的代码中增加对number的支持就行，然后前台增加会员卡一项内容的表现与处理即可。
4、UserDAL.cs
public IList<UserInfo>SelectUsers()：返回所有的用户信息列表
public UserInfo SelectUser(int UserId)：返回指定用户的相信信息
public bool InsertUser(UserInfo User)：新增用户信息
public bool UpdateUser(UserInfo User)：更新用户信息
public void DeleteUser(int UserId)：移除用户信息
很多人最闹不清的就是数据访问层，到底那部分才算数据访问层呢？有些认为数据库就是数据访问层，这是对定义没有搞清楚，DAL是数据访问层而不是数据存储层，因此数据库不可能是这一层的。也有的把SQLHelper（或其同类作用的组件）作为数据访问层，它又是一个可有可无的东西，SQLHelper的作用是减少重复性编码，提高编码效率，因此如果我习惯在乎效率或使用一个非数据库的数据源时，可以丢弃SQLHelper，一个可以随意弃置的部分，又怎么能成为三层架构中的一层呢。
可以这样定义：与数据源操作有关的代码，就应该放在数据访问层中，属于数据访问层
5、IUserDAL
数据访问层接口，这又是一个可有可无的东西，因为Petshop中带了它和ClassFactory类工厂，所以有些项目不论需不需要支持多数据源，都把这两个东西做了进来，有的甚至不建ClassFactory而只建了IDAL，然后“IUserDAL iUserDal = new UserDAL();”，不知意义何在。这就完全是画虎不成反类犬了。
许多人在这里有一个误解，那就是以为存在这样的关系：BLLßàIDALßàDAL，认为IDAL起到了BLL和DAL之间的桥梁作用，BLL是通过IDAL来调用DAL的。但实际是即使你如此编码：“IUserDAL iUserDal =ClassFacotry.CreateUserDAL()；”，那么在执行“iUserDal.SelectUsers()”时，其实还是执行的UserDAL实例，而不是IUserDAL实例，所以IDAL在三层中的位置是与DAL平级的关系。
通过上面的介绍，基本上将三层架构的层次结构说明了。其实，本人有一个判断三层架构是否标准的方法，那就是将三层中的任意一层完全替换，都不会对其它两层造成影响，这样的构造基本就符合三层标准了（虽然实现起来比较难^_^）。例如如果将项目从B/S改为C/S（或相反），那么除了UI以外，BLL与DAL都不用改动；或者将SQLServer改为Oracle，只需替换SQLServerDAL到OracleDAL，无需其它操作等等。本来想在文中加入一些具体的代码的，但感觉不是很必要，如果大家觉得需要的话，我再补充吧。
总结：不要因为某个层对你来说没用，或者实现起来特别简单，就认为它没有必要，或者摒弃它，或者挪作它用。只要进行了分层，不管是几层，每一层都要有明确的目的和功能实现，而不要被实际过程所左右，造成同一类文件位于不同层的情况发生。也不要出现同一层实现了不同的功能的情况发生。
常用的三层架构设计
软件系统最常用的一般会讲到三层架构，其实就是将整个业务应用划分为表示层、业务逻辑层、数据访问层等，有的还要细一些，通过分解业务细节，将不同的功能代码分散开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元，十分有利于系统的维护和扩展。
常见的三层架构基本包括如下几个部分，如图14-1所示。
图14-1 常见的三层架构
l 数据访问层DAL：用于实现与数据库的交互和访问，从数据库获取数据或保存数据到数据库的部分。
2 业务逻辑层BLL：业务逻辑层承上启下，用于对上下交互的数据进行逻辑处理，实现业务目标。
3 表示层Web：主要实现和用户的交互，接收用户请求或返回用户请求的数据结果的展现，而具体的数据处理则交给业务逻辑层和数据访问层去处理。
日常开发的很多情况下为了复用一些共同的东西，会把一些各层都用的东西抽象出来。如我们将数据对象实体和方法分离，以便在多个层中传递，例如称为Model。一些共性的通用辅助类和工具方法，如数据校验、缓存处理、加解密处理等，为了让各个层之间复用，也单独分离出来，作为独立的模块使用，例如称为Common。
此时，三层架构会演变为如图14-2所示的情况。
图14-2 三层架构演变结果
4 业务实体Model：用于封装实体类数据结构，一般用于映射数据库的数据表或视图，用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦，为了更好地发挥分层的作用，更好地进行复用和扩展，增强灵活性。
5 通用类库Common：通用的辅助工具类。
在第5.2节中我们讲过可以将对数据库的共性操作抽象封装成数据操作类（例如DbHelperSQL），以便更好地复用和使代码简洁。数据层底层使用通用数据库操作类来访问数据库，最后完整的三层架构如图14-3所示。
图14-3 最后完整的三层架构
数据库访问类是对ADO.NET的封装，封装了一些常用的重复的数据库操作。如微软的企业库SQLHelper.cs，动软的DBUtility/DbHelperSQL等，为DAL提供访问数据库的辅助工具类。
通过以上分析，我们知道如今常用的三层架构是个什么样子，同时，我们也知道了三层架构在使用过程中的一些演化过程。那么，为什么要这样分层，每层结构到底又起什么作用呢？我们继续往下看。
趣味理解：三层架构与养猪
看新闻报道今年猪肉价格一路高涨，据说有人养猪都发财致富奔小康了，程序员都说写代码没前途了，还不如去养猪，不过，可别认为养猪没有技术含量，比写代码容易，其实养猪也大有学问。为了更好地理解三层架构，就拿养猪来做个例子吧。俗话说：“没吃过猪肉，还没见过猪跑啊！”。
图14-4是三层架构化的养猪产业流水线趣味对此图。
图14-4三层结构与养猪
对比图14-3与图14-4，我们可以看出：
- 数据库好比猪圈，所有的猪有序地按区域或编号，存放在不同的猪栏里。
- DAL好比是屠宰场，把猪从猪圈取出来进行（处理）屠杀，按要求取出相应的部位（字段），或者进行归类整理（统计），形成整箱的猪肉（数据集），传送给食品加工厂（BLL）。本来这里都是同一伙人既管抓猪，又管杀猪的，后来觉得效率太低了，就让一部分人出来专管抓猪了（DBUtility），根据要求来抓取指定的猪。
- BLL好比食品加工厂，将猪肉深加工成各种可以食用的食品（业务处理）。
- Web好比商场，将食品包装成漂亮的可以销售的产品，展现给顾客（UI表现层）。
- 猪肉好比Model，无论是哪个厂（层），各个环节传递的本质都是猪肉，猪肉贯穿整个过程。
- 通用类库Common相当于工人使用的各种工具，为各个厂（层）提供诸如杀猪刀、绳子、剪刀、包装箱、工具车等共用的常用工具（类）。其实，每个部门本来是可以自己制作自己的工具的，但是那样会使效率比较低，而且也不专业，并且很多工作都会是重复的。因此，就专门有人开了这样的工厂来制作这些工具，提供给各个工厂，有了这样的分工，工厂就可以专心做自己的事情了。
当然，这里只是形象的比喻，目的是为了让大家更好地理解，实际的情况在细节上会有所不同。这个例子也只是说明了从猪圈到商场的单向过程，而实际三层开发中的数据交互是双向的，可取可存。不过，据说有一种机器，把猪从这头赶进去，另一头就噗噗噜噜地出火腿肠了。如果火腿肠卖不了了，从那头再放进去，这头猪又原原本本出来了，科幻的机器吧，没想到也可以和三层结构联系上。以上只是笑谈，不过也使三层架构的基本概念更容易理解了。
上面谈了那么多，有人会问，我直接从数据库取出内容直接操作不可以吗？为什么要这么麻烦地用三层架构呢？三层架构到底有什么好处呢？
不分层，当然可以，就好比整个过程不分屠宰场、加工场之类的，都在同一个场所（工厂）完成所有的活（屠杀、加工、销售）。但为什么要加工厂和商场呢？因为当规模比较大的时候，管理起来就会变得非常复杂，这样的养殖方式已经无法满足规模化的需要了。并且，从社会的发展来看，社会分工是人类进步的表现。社会分工的优势就是让适合的人做自己擅长的事情，使平均社会劳动时间大大缩短，生产效率显著提高。能够提供优质高效劳动产品的人才能在市场竞争中获得高利润和高价值。人尽其才，物尽其用最深刻的含义就是由社会分工得出的。软件开发也一样，做小项目的时候，分不分层确实看不出什么差别，并且显得更麻烦啰嗦了。但当项目变大和变复杂时，分层就显示出它的优势来了。所以分不分层要根据项目的实际情况而定，不能一概而论。
Oop 三层架构
应用系统架构
继承
封装
抽象
三层架构
Ui 表现层
功能单一
复杂的逻辑不能写在表现层
SQL 不能写
Bl 业务逻辑层
循环 算法 异常通知 事件通知
和表现层有关 的
和SQL 语句有关的
Da 数据库访问 层
功能简单
提供的方法都是常用 的数据类型 通用的数据
有三层结构引发 设计模式 （固定思路）
如：人事管理
实体 实体的管理器
管理器与数据访问层接触
外观模式（
Facade外观模式，是一种结构型模式，它主要解决的问题是：组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。在这里我想举一个例子：比如，现在有一辆汽车，我们（客户程序）要启动它，那我们就要发动引擎（子系统1），使四个车轮（子系统2）转动。但是实际中我们并不需要用手推动车轮使其转动，我们踩下油门，此时汽车再根据一些其他的操作使车轮转动。油门就好比系统给我们留下的接口，不论汽车是以何种方式转动车轮，车轮变化成什么牌子的，我们要开走汽车所要做的还是踩下油门。
GoF《设计模式》中说道：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Façade外观模式的结构大概是这样的：
这个图是我对Facade模式的理解，如果大家觉得有什么不对的地方欢迎给我指出。
我就上面说的那个情形写一下实现代码，首先我们要实现三个子系统（Wheel、Engine、Body）：
internal class Engine
{
public string EngineWork()
{
return "BMW's Engine is Working";
}
public string EngineStop()
{
return "BMW's Engine is stoped";
}
}
internal class Wheel
{
public string WheelCircumrotate()
{
return "BMW's Wheel is Circumrotating";
}
public string WheelStop()
{
return "BMW's Wheel is stoped";
}
}
internal class Body
{
public Wheel[]wheels = new Wheel[4];
public Engine engine= new Engine();
public Body()
{
for (int i = 0; i < wheels.Length; i++)
{
wheels[i] = new Wheel();
}
}
}
然后，我们再来实现汽车的Facade
class CarFacade
{
Body body = new Body();
public void Run()
{
Console.WriteLine(body.engine.EngineWork());
for(int i = 0; i < body.wheels.Length; i++)
{
Console.WriteLine(body.wheels[i].WheelCircumrotate());
}
}
public void Stop()
{
Console.WriteLine(body.engine.EngineStop());
for (int i = 0; i < body.wheels.Length; i++)
{
Console.WriteLine(body.wheels[i].WheelStop());
}
}
}
现在我们来使用客户端程序验证一下，代码如下：
class Program
{
static void Main(string[] args)
{
CarFacade car = new CarFacade();
car.Run();
car.Stop();
Console.Read();
}
}
执行结果如下；
BMW's Engine is Working
BMW's Wheel is Circumrotating
BMW's Wheel is Circumrotating
BMW's Wheel is Circumrotating
BMW's Wheel is Circumrotating
BMW's Engine is stoped
BMW's Wheel is stoped
BMW's Wheel is stoped
BMW's Wheel is stoped
BMW's Wheel is stoped
正如上面所说：客户端代码（Program）不需要关心子系统，它只需要关心CarFacade所留下来的和外部交互的接口，而子系统是在CarFacade中聚合。
Façade模式的几个要点：
1、从客户程序的角度看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
2、Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
）
外观
界面与表现层
在数据访问层加 一个
Comment（通用层）
一般都是从上往下的
从下往上 事件机制 （2种）
软件 visio (
流程图
组织结构
DB
Uml
)
软件
Project
流程图与组织结构图
系统中的功能点已经功能点的所属结构
组织结构图（Organization Chart），是最常见的表现雇员、职称和群体关系的一种图表，它形象地反映了组织内各机构、岗位上下左右相互之间的关系。组织结构图是组织结构的直观反映，也是对该组织功能的一种侧面诠释。
1. 可以显示其职能的划分.
2. 可以知道其权责是否适当.
3. 可以看出该人员的工作负荷是否过重.
4. 可以看出是否有无关人员承担几种较松散,无关系的工作.
5. 可以看出是否有让有才干的人没有发挥出来的情形.
6. 可以看出有没有让不胜任此项工作的人担任的重要职位.
7. 可以看出晋升的渠道是否畅通.
8. 可以显示出下次升级时谁是最合适的人选.
9. 可以使各人清楚自己组织内的工作,加强其参与工作的欲望,其他部门的人员也可以明了,增强组织的协调性.
编辑本段组织结构图的类型
组织结构图的类型，由组织的结构类型所决定。以下为几种基本的组织结构：
流程图
流程图：使用图形表示算法的思路是一种极好的方法，因为千言万语不如一张图。流程图在汇编语言和早期的BASIC语言环境中得到应用.相关的还有一种PAD图，对PASCAL或C语言都极适用。
以特定的图形符号加上说明，表示算法的图，称为流程图或框图。
流程图是流经一个系统的信息流、观点流或部件流的图形代表。在企业中，流程图主要用来说明某一过程。这种过程既可以是生产线上的工艺流程，也可以是完成一项任务必需的管理过程。
例如，一张流程图能够成为解释某个零件的制造工序，甚至组织决策制定程序的方式之一。这些过程的各个阶段均用图形块表示，不同图形块之间以箭头相连，代表它们在系统内的流动方向。下一步何去何从，要取决于上一步的结果，典型做法是用“是”或“否”的逻辑分支加以判断。
流程图是揭示和掌握封闭系统运动状况的有效方式。作为诊断工具，它能够辅助决策制定，让管理者清楚地知道，问题可能出在什么地方，从而确定出可供选择的行动方案。
流程图有时也称作输入-输出图。该图直观地描述一个工作过程的具体步骤。流程图对准确了解事情是如何进行的，以及决定应如何改进过程极有帮助。这一方法可以用于整个企业，以便直观地跟踪和图解企业的运作方式。
流程图使用一些标准符号代表某些类型的动作，如决策用菱形框表示，具体活动用方框表示。但比这些符号规定更重要的，是必须清楚地描述工作过程的顺序。流程图也可用于设计改进工作过程，具体做法是先画出事情应该怎么做，再将其与实际情况进行比较。
编辑本段绘制流程图的步骤
为便于识别，绘制流程图的习惯做法是：
圆角矩形表示“开始”与“结束”。
矩形表示行动方案、普通工作环节用
菱形表示问题判断或判定（审核/审批/评审）环节
用平行四边形表示输入输出
箭头代表工作流方向
编辑本段使用流程图需要考虑的问题
使用流程图需要考虑很多问题，如：
过程中是否存在某些环节，删掉它们后能够降低成本或减少时间？
还有其他更有效的方式构造流程吗？
整个过程是否因为过时而需要重新设计？
应当将其完全废弃吗？
编辑本段定义
流程图是由一些图框和流程线组成的，其中图框表示各种操作的类型，图框中的文字和符号表示操作的内容，流程线表示操作的先后次序。
编辑本段基本结构
顺序结构，分支结构（又称选择结构），循环结构。
编辑本段流程图符号及约定
数据流程图数据流程图表示求解某一问题的数据通路.同时规定了处理的主要阶段和所用的各种数据媒体.
数据流程图包括：
a. 指明数据存在的数据符号，这些数据符号也可指明该数据所使用的媒体；
b. 指明对数据执行的处理的处理符号，这些符号也可指明该处理所用到的机器功能；
c. 指明几个处理和（或）数据媒体之间的数据流的流线符号；
d. 便于读.写数据流程图的特殊符号.
在处理符号的前后都应是数据符号.数据流程图以数据符号开始和结束（除9.4规定的特殊符号外）
程序流程图
程序流程图表示程序中的操作顺序.
程序流程图包括：
a. 指明实际处理操作的处理符号，它包括根据逻辑条件确定要执行的路径的符号；
b. 指明控制流的流线符号；
c. 便于读.写程序流程图的特殊符号.
系统流程图
系统流程图表示系统的操作控制和数据流.
系统流程图包括：
a. 指明数据存在的数据符号，这些数据符号也可指明该数据所使用的媒体；
b. 定义要执行的逻辑路径以及指明对数据执行的操作的处理符号；
c. 指明各处理和（或）数据媒体间数据流的流线符号；
d. 便于读.写系统流程图的特殊符号.
程序网络图
程序网络图表示程序激活路径和程序与相关数据的相互作用.在系统流程图中，一个程序可能在
多个控制流中出现；但在程序网络图中，每个程序仅出现一次.
程序网络图包括；
a. 指明数据存在的数据符号；
b. 指明对数据执行的操作的处理符号；
c. 表明各处理的激活和处理与数据间流向的流线符号；
d. 便于读.写程序网络图的特殊符号.
系统资源图
系统资源图表示适合于一个问题或一组问题求解的数据单元和处理单元的配置.
系统资源图包括：
a. 表明输入.输出或存储设备的数据符号；
b. 表示处理器（如中央处理机.通道等）的处理符号；
c. 表示数据设备和处理器间的数据传输以及处理器之间的控制传送的流线符号；
d. 便于读.写系统资源图的特殊符号.[1]
编辑本段可以画流程图的软件有哪些
visual graph专业图形系统：此系统为图形控件，在.NET开发平台下可以灵活应用，delphi中也可以使用。简单易用，业内应用较广泛。
Visio是当今最优秀的绘图软件之一，它将强大的功能和易用性完美结合，可广泛应用于电子、机械、通信、建筑、软件设计和企业管理等众多领域。
powerdesigner是一款比较不错的画流程图软件。
SAM业务流程梳理工具软件，为流程从业者梳理流程业务提供便捷、标准化的建模工具，为开展流程梳理、固化、发布工作提供最佳工具支持。
visio是微软公司推出的非常传统的免费流程图软件，应用范围广泛。采用泳道图的方式能够把流程和流程的部门以及岗位关联起来，实现流程和所有者的对应。随着企业对流程管理应用需求的提升，片段、静态的方式逐渐很难适应企业实际流程管理的需要。
control是英国nimbus公司的流程软件，采用全息的方式能够比较全面地展示流程的基本要素，包括活动、输入输出、角色以及相关的文档等各种信息。具有简洁易用的特性，不支持多维度扩展应用。
aris是IDS公司的流程软件，具有IDS特有的多维建模和房式结构，集成了流程管理平台，可以通过流程平台进行流程分析和流程管理。
provision是metastorm公司的流程软件，以多维度系统建模见长，能够集成企业的多种管理功能，是流程管理专家级客户应用的工具。
防火墙
路由器
核心交换机
Web 服务器
跨域（
javascript出于安全方面的考虑，是不允许跨域调用其他页面的对象的。但在安全限制的同时也给注入iframe或是ajax应用上带来了不少麻烦。没有记错的话前三届D2论坛上每次都有人提这个东西，这里把涉及到跨域的一些问题简单地整理一下：
首先什么是跨域，简单地理解就是因为javascript同源策略的限制，a.com 域名下的js无法操作b.com或是c.a.com域名下的对象。更详细的说明可以看下表：
| URL |
说明 |
是否允许通信 |
| http://www.kuqin.com/lab/a.js |
同一域名下不同文件夹 |
允许 |
| http://www.kuqin.com/a.js |
同一域名下 |
允许 |
| http://www.kuqin.com:8000/a.js |
同一域名，不同端口 |
不允许 |
| http://www.kuqin.com/a.js |
同一域名，不同协议 |
不允许 |
| http://www.kuqin.com/a.js |
域名和域名对应ip |
不允许 |
| http://www.kuqin.com/a.js |
主域相同，子域不同 |
不允许 |
| http://www.ithao123.com/a.js |
不同域名 |
不允许 |
特别注意两点：
第一，如果是协议和端口造成的跨域问题“前台”是无能为力的，
第二：在跨域问题上，域仅仅是通过URL的首部来识别而不会去尝试判断相同的ip地址对应着两个域或两个域是否在同一个ip上。
接下来简单地总结一下在“前台”一般处理跨域的办法，后台proxy这种方案牵涉到后台的配置，这里就不阐述了,有兴趣的可以看看YAHOO的这篇文章：
JavaScript: Use a Web Proxy for Cross-Domain XMLHttpRequest Calls。
1、document.domain+iframe的设置
对于主域相同而子域不同的例子，可以通过设置document.domain的办法来解决。具体的做法是可以在http://www.kuqin.com/a.html和http://script.kuqin.com/b.html两个文件中分别加上document.domain =‘kuqin.com’；然后通过a.html文件中创建一个iframe,去控制iframe的contentDocument,这样两个js文件之间就可以“交互”了。当然这种办法只能解决主域相同而二级域名不同的情况，如果你异想天开的把script.kuqin.com的domian设为alibaba.com那显然是会报错地！代码如下：
www.kuqin.com上的a.html
|
1 2 3 4 5 6 7 8 9 |
document.domain = "kuqin.com"; var ifr = document.createElement("iframe"); ifr.src = "http://script.kuqin.com/b.html"; ifr.style.display = "none"; document.body.appendChild(ifr); ifr.onload = function(){ var x = ifr.contentDocument; alert(x.getElementsByTagName("h1")[0].childNodes[0].nodeValue); } |
script.kuqin.com上的b.html
|
1 |
document.domain = "kuqin.com"; |
2、动态创建script
虽然浏览器默认禁止了跨域访问，但并不禁止在页面中引用其他域的JS文件，并可以自由执行引入的JS文件中的function，根据这一点，可以方便地通过创建script节点的方法来实现完全跨域的通信。具体的做法可以参考yui的 Get Utility
这里判断script节点加载完毕还是蛮有意思的：ie只能通过script的readystatechange属性,Safari 3.x以上支持的是script的load事件，而firefox和oprea则要通过onload来解决。另外这种办法只能传递js类型的数据，不是很方便。以下是部分判断script加载完毕的方法。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
……
// ie支持script的readystatechange属性 // IE supports the readystatechange event for script and css nodes if (ua.ie) { n.onreadystatechange = function() { var rs = this.readyState; if ("loaded" === rs || "complete" === rs) { n.onreadystatechange = null; f(id, url); } };
……
// // Safari 3.x supports the load event for script nodes (DOM2)
……
n.addEventListener("load", function() { f(id, url); });
……
// FireFox and Opera support onload (but not DOM2 in FF) handlers for // script nodes. Opera, but not FF, supports the onload event for link // nodes. } else { n.onload = function() { f(id, url); }; } |
3、利用iframe和location.hash
这个办法比较绕，但是可以解决完全跨域情况下的脚步置换问题。原理是利用location.hash来进行传值。在url： http://kuqin.com#helloword中的‘#helloworld’就是location.hash,改变hash并不会导致页面刷新，所以可以利用hash值来进行数据传递，当然数据容量是有限的。假设域名kuqin.com下的文件cs1.html要和ithao123.com域名下的cs2.html传递信息，cs1.html首先创建自动创建一个隐藏的iframe，iframe的src指向ithao123.com域名下的cs2.html页面，这时的hash值可以做参数传递用。cs2.html响应请求后再将通过修改cs1.html的hash值来传递数据。（因为ie不允许修改parent.location.hash的值，所以要借助于kuqin.com域名下的一个代理iframe）。同时在cs1.html上加一个定时器，隔一段时间来判断location.hash的值有没有变化，一点有变化则获取获取hash值。代码如下：
先是kuqin.com下的文件cs1.html文件：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
function startRequest(){ var ifr = document.createElement("iframe"); ifr.style.display = "none"; ifr.src = "http://www.ithao123.com/lab/cscript/cs2.html#paramdo"; document.body.appendChild(ifr); }
function checkHash() { try { var data = location.hash ? location.hash.substring(1):""; if(console.log){ console.log("Now the data is "+data); } }catch(e){}; } setInterval(checkHash, 2000); |
ithao123.com域名下的cs2.html:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
(function(){ //模拟一个简单的参数处理操作 switch(location.hash){ case "#paramdo": callBack(); break; case "#paramset": //do something…… break; }
function callBack(){ try { parent.location.hash = "somedata"; } catch (e) { //ie的安全机制无法修改parent.location.hash,所以要利用一个中间在ithao123域下的代理iframe var ifrproxy = document.createElement("iframe"); ifrproxy.style.display = "none"; ifrproxy.src = "http://kuqin.com/test/cscript/cs3.html#somedata"; document.body.appendChild(ifrproxy); } } })(); |
kuqin.com下的域名cs3.html
|
1 2 |
//因为parent.parent和自身属于同一个域，所以ie下可以改变其location.hash的值 parent.parent.location.hash = self.location.hash.substring(1); |
实例请点击 hash实现完全跨域
当然这样做也存在很多缺点，诸如数据直接暴露在了url中，数据容量和类型都有限等……
4、利用flash
这是从YUI3的IO组件中看到的办法,具体可见：http://developer.yahoo.com/yui/3/io/
flash这个方案不是很明白，各位自己慢慢琢磨了，呵呵。你可以看在Adobe Developer Connection看到更多的跨域代理文件规范：
ross-Domain Policy FileSpecifications.
HTTP Headers Blacklist.
跨域请求，顾名思义，就是一个站点中的资源去访问另外一个不同域名站点上的资源。这种情况很常见，比如说通过 style 标签加载外部样式表文件、通过 img 标签加载外部图片、通过 script 标签加载外部脚本文件、通过 Webfont 加载字体文件等等。默认情况下，脚本访问文档属性等数据采用的是同源策略（Same origin policy）。
那么，什么是同源策略呢？如果两个页面的协议、域名和端口是完全相同的，那么它们就是同源的。同源策略是为了防止从一个地址加载的文档或脚本访问或者设置从另外一个地址加载的文档的属性。如果两个页面的主域名相同，则还可以通过设置 document.domain 属性将它们认为是同源的。
随着 Web2.0 和 SNS 的兴起，Web 应用对跨域访问的需求也越来越多，但是，在脚本中进行跨域请求是受安全性限制的，Web 开发人员迫切需要提供一种更安全、方便的跨域请求方式来融合（Mashup）自己的 Web 应用。这样做的一个好处就是可以将请求分摊到不同的服务器，减轻单个服务器压力以提高响应速度；另外一个好处是可以将不同的业务逻辑分布到不同的服务器上以降低负载。
值得庆幸的是，跨域请求的标准已经出台，主流浏览器也已经实现了这一标准。W3C 工作组中的 Web ApplicationsWorking Group（Web 应用工作组）发布了一个 Cross-Origin Resource Sharing（跨域资源共享，该规范地址：http://www.w3.org/TR/access-control/和http://dev.w3.org/2006/waf/access-control/） 推荐规范来解决跨域请求的问题。该规范提供了一种更安全的跨域数据交换方法。具体规范的介绍可以访问上面提供的网站地址。值得注意的是：该规范只能应用在类似 XMLHttprequest 这样的 API 容器内。IE8、Firefox 3.5 及其以后的版本、Chrome浏览器、Safari 4 等已经实现了 Cross-Origin Resource Sharing 规范，已经可以进行跨域请求了。
Cross-Origin Resource Sharing 的工作方式是通过添加 HTTP 头的方法来判断哪些资源允许 Web 浏览器访问该域名下的信息。然而，对于那些 HTTP 请求导致用户数据产生副作用的请求方法（特别是对于除了GET、某些 MIME 类型的 POST 之外的 HTTP方法），该规范要求浏览器对请求进行“预先验”，通过发送 HTTP 的 OPTIONS 请求头询问服务器有哪些支持的方法，在征得服务器的同意后，再使用实际的 HTTP 请求方法发送实际的请求。服务器也可以通知客户端是否需要将验证信息（如 Cookie 和 HTTP Authentication 数据）随同请求一起发送。
下面我们就采用实际的例子说明 Cross-OriginResource Sharing 是如何工作的。
1，简单请求
什么样的请求算是简单请求呢？简单请求必须满足下面2点：
a，只使用 GET、POST 进行的请求，这里的POST只包括发送给服务器的数据类型（Content-Type）必须是application/x-www-form-urlencoded、multipart/form-data 或者 text/plain中一个。
b，HTTP 请求没有设置自定义的请求头，如我们常用的 X-JSON。
先使用下面的代码进行测试：
view plain
1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
2. "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3. <html xmlns="http://www.w3.org/1999/xhtml">
4. <head>
5. <title>孟宪会之AJAX跨域请求测试</title>
6. </head>
7. <body>
8. <input type='button' value='开始测试' onclick='crossDomainRequest()' />
9. <div id="content"></div>
10. <mce:script type="text/javascript"><!--
11. var xhr = new XMLHttpRequest();
12. var url = 'http://dotnet.aspx.cc/SimpleCrossSiteRequests.aspx';
13. function crossDomainRequest() {
14. document.getElementById("content").innerHTML = "开始……";
15. if (xhr) {
16. xhr.open('GET', url, true);
17. xhr.onreadystatechange = handler;
18. xhr.send();
19. } else {
20. document.getElementById("content").innerHTML = "不能创建 XMLHttpRequest";
21. }
22. }
23. function handler(evtXHR) {
24. if (xhr.readyState == 4) {
25. if (xhr.status == 200) {
26. var response = xhr.responseText;
27. document.getElementById("content").innerHTML = "结果：" + response;
28. } else {
29. document.getElementById("content").innerHTML = "不允许跨域请求。";
30. }
31. }
32. else {
33. document.getElementById("content").innerHTML += "<br/>执行状态 readyState：" + xhr.readyState;
34. }
35. }
36. // --></mce:script>
37. </body>
38. </html>
然后，在服务器创建CrossDomainRequest.aspx 的内容如下：
view plain
1. <%@ Page Language="C#" %>
2. <mce:script runat="server"><!--
3. protected void Page_Load(object sender, EventArgs e)
4. {
5. Response.AddHeader("Access-Control-Allow-Origin", "http://www.meng_xian_hui.com:801");
6. Response.Write("孟宪会向各位朋友发来贺电：你的第一个跨域测试成功啦！！！");
7. }
8. // --></mce:script>
点击 “开始测试” 按钮，发送的请求和返回的响应信息如下：
view plain
1. GET /SimpleCrossSiteRequests.aspx HTTP/1.1
2. Host: dotnet.aspx.cc
3. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; zh-CN; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
4. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5. Accept-Language: zh-cn,zh;q=0.5
6. Accept-Encoding: gzip,deflate
7. Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
8. Keep-Alive: 300
9. Connection: keep-alive
10. Referer: http://www.meng_xian_hui.com:801/CrossDomainAjax/SimpleCrossSiteRequests.html
11. Origin: http://www.meng_xian_hui.com:801
12. HTTP/1.x 200 OK
13. Date: Sun, 10 Jan 2010 13:52:00 GMT
14. Server: Microsoft-IIS/6.0
15. X-Powered-By: ASP.NET
16. X-AspNet-Version: 2.0.50727
17. Access-Control-Allow-Origin: http://www.meng_xian_hui.com:801
18. Set-Cookie: ASP.NET_SessionId=wk5v5nrs5wbfi4rmpjy2jujb; path=/; HttpOnly
19. Cache-Control: private
20. Content-Type: text/html; charset=utf-8
21. Content-Length: 84
需要特别注意的是：在请求信息中，浏览器使用 Origin 这个 HTTP 头来标识该请求来自于 http://www.meng_xian_hui.com:801；在返回的响应信息中，使用 Access-Control-Allow-Origin 头来控制哪些域名的脚本可以访问该资源。如果设置 Access-Control-Allow-Origin:*，则允许所有域名的脚本访问该资源。如果有多个，则只需要使用逗号分隔开即可。
注意：在服务器端，Access-Control-Allow-Origin响应头http://www.meng_xian_hui.com:801 中的端口信息不能省略。
有人可能会想：自己发送请求头会如何呢？比如xhr.setRequestHeader("Origin","http://www.meng_xian_hui.com:801");实践证明，自己设置 Origin 头是不行的。
是不是现在就可以采用 XMLHttpRequest 来请求任意一个网站的数据呢？还是不行的。允许哪些域名可以访问，还需要服务器来设置 Access-Control-Allow-Origin 头来进行授权，具体的代码是：
Response.AddHeader("Access-Control-Allow-Origin","http://www.meng_xian_hui.com:801");
这行代码就告诉浏览器，只有来自http://www.meng_xian_hui.com:801 源下的脚本才可以进行访问。
好了，上面我们就完成了一个简单的跨域请求，怎么样？感觉还是不错的吧。下面我们进行一个“预检”请求。
）
Active x
Flash/silverlight
应用程序服务器
网站访问应用程序（
Sendmessages （window）
Socket 2 qq
远程
Socket
Self-hostedservice
）
数据库服务器
Er（实体关系）
级联更新
聚集索引（最常用的）
（
聚集索引和非聚集索引的区别:
汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。
我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。
通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。
进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。
得出查询速度的方法是：在各个select语句前加：declare @d datetime
set @d=getdate()
并在select语句后加：
select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
1、用聚合索引比用不是聚合索引的主键速度快
2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下
事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的速度差别不明显。
3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个
4 、日期列不会因为有分秒的输入而减慢查询速度
从publish 表中取出第 n 条到第 m 条的记录：
SELECT TOP m-n+1 *
FROM publish
WHERE (id NOT IN
(SELECT TOP n-1 id
FROM publish))
id 为publish 表的关键字
只所以把“查询优化”和“分页算法”这两个联系不是很大的论题放在一起，就是因为二者都需要一个非常重要的东西――聚集索引。
在前面的讨论中我们已经提到了，聚集索引有两个最大的优势：
1、以最快的速度缩小查询范围。
2、以最快的速度进行字段排序。
第1条多用在查询优化时，而第2条多用在进行分页时的数据排序。
而聚集索引在每个表内又只能建立一个，这使得聚集索引显得更加的重要。聚集索引的挑选可以说是实现“查询优化”和“高效分页”的最关键因素。
但要既使聚集索引列既符合查询列的需要，又符合排序列的需要，这通常是一个矛盾。
聚集索引是如此的重要和珍贵，所以一定要将聚集索引建立在：
1、您最频繁使用的、用以缩小查询范围的字段上；
2、您最频繁使用的、需要排序的字段上。
主键(PRIMARY KEY )
来自MSDN的描述：
表通常具有包含唯一标识表中每一行的值的一列或一组列。这样的一列或多列称为表的主键 (PK)，用于强制表的实体完整性。在创建或修改表时，您可以通过定义 PRIMARYKEY 约束来创建主键。
一个表只能有一个 PRIMARY KEY 约束，并且 PRIMARY KEY 约束中的列不能接受空值。由于 PRIMARY KEY 约束可保证数据的唯一性，因此经常对标识列定义这种约束。
如果为表指定了 PRIMARY KEY 约束，则 SQL Server 2005 数据库引擎将通过为主键列创建唯一索引来强制数据的唯一性。当在查询中使用主键时，此索引还可用来对数据进行快速访问。因此，所选的主键必须遵守创建唯一索引的规则。
创建主键时，数据库引擎 会自动创建唯一的索引来强制实施 PRIMARY KEY 约束的唯一性要求。如果表中不存在聚集索引或未显式指定非聚集索引，则将创建唯一的聚集索引以强制实施 PRIMARY KEY 约束。
聚集索引
聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。
每个表几乎都对列定义聚集索引来实现下列功能：
· 可用于经常使用的查询。
· 提供高度唯一性。
两者的比较
下面是一个简单的比较表
|
|
主键 |
聚集索引 |
| 用途 |
强制表的实体完整性 |
对数据行的排序，方便查询用 |
| 一个表多少个 |
一个表最多一个主键 |
一个表最多一个聚集索引 |
| 是否允许多个字段来定义 |
一个主键可以多个字段来定义 |
一个索引可以多个字段来定义 |
|
|
|
|
| 是否允许 null 数据行出现 |
如果要创建的数据列中数据存在null，无法建立主键。 |
没有限制建立聚集索引的列一定必须 not null . |
| 是否要求数据必须唯一 |
要求数据必须唯一 |
数据即可以唯一，也可以不唯一。看你定义这个索引的 UNIQUE 设置。 |
|
|
|
|
| 创建的逻辑 |
数据库在创建主键同时，会自动建立一个唯一索引。 |
如果未使用 UNIQUE 属性创建聚集索引，数据库引擎 将向表自动添加一个四字节 uniqueifier 列。 |
）
Orm(
对象关系映射（ObjectRelational Mapping，简称ORM）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销；然而，如果ORM作为一种中间件实现，则会有很多机会做优化，而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理；但是同样，这些花费要比维护手写的方案要少；而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。
对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。
面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。
让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。
当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码，用来从数据库保存，删除，读取对象信息，等等。你在DAL中写了很多的方法来读取对象数据，改变状态对象等等任务。而这些代码写起来总是重复的。
如果打开你最近的程序，看看DAL代码，你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例，你传入一个对象，为SqlCommand对象添加SqlParameter，把所有属性和对象对应，设置SqlCommand的CommandText属性为存储过程，然后运行SqlCommand。对于每个对象都要重复的写这些代码。
除此之外，还有更好的办法吗？有，引入一个O/R Mapping。实质上，一个O/R Mapping会为你生成DAL。与其自己写DAL代码，不如用O/R Mapping。你用O/R Mapping保存，删除，读取对象，O/R Mapping负责生成SQL，你只需要关心对象就好。
对象关系映射成功运用在不同的面向对象持久层产品中，如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。
一般的ORM包括以下四部分：
一个对持久类对象进行CRUD操作的API；
一个语言或API用来规定与类和类属性相关的查询；
一个规定mapping metadata的工具；
一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。
一、目前流行的 ORM 产品
目前众多厂商和开源社区都提供了持久层框架的实现，常见的有：
Apache OJB （http://db.apache.org/ojb/）
Cayenne （http://objectstyle.org/cayenne/）
Jaxor （http://jaxor.sourceforge.net）
Hibernate （http://www.hibernate.org）
iBatis （http://www.ibatis.com）
jRelationalFramework （http://ijf.sourceforge.net）
mirage （http://itor.cq2.org/en/oss/mirage/toon）
SMYLE （http://www.drjava.de/smyle）
TopLink （http://otn.oracle.com/products/ias/toplink/index.html）
其中 TopLink 是 Oracle 的商业产品，其他均为开源项目。
其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准，这也是开源项目影响工业领域标准的有力见证。
二、对象－关系映射模式
从《公共仓库元模型：开发指南》一书第8章CWM元仓库中摘录出来的内容，实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射，是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。
基本情况：公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准，采用UML表示的对象层次结构，在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流)，所以该书的作者倾向于使用成熟的关系型数据库来保存－这也是存储本体时所遇到的问题。
采用方法：将UML模型中的各种元素通过转换，保存为数据库模式。由于CWM是一种元模型，因此模型的实例也是一种模型，将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术提高开发和执行效率。
1、数据类型映射模式
1.1简单数据类型模式：建立UML和关系型数据库中简单数据类型的映射表以指导映射。
1.2枚举数据类型模式：每种枚举类型对应一个表，只有一个列(_EnumLiteral)表示枚举值。
1.3基于类的数据类型模式：使用外键约束，将基础列与基于类的类型实例相关联。
2、类映射模型
每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射，而引用属性将在关联映射模式中提到。
2.1单值属性模式：是cardinality的上界为1的属性，映射到类所对应的表的列上。若其下界也为1（必须有的属性），列属性为NOT NULL。
2.2多值属性模式：每个多值属性映射成一个独立的表，使用外键连接到类所对应的表上。
2.3继承模式：每加入一个类的实例时，根据其继承关系自顶向下生成每个类的对象，这些对象具有相同的ID（根对象对应记录的主键）。删除对象实例时，自底向上删除数据。遇到从中间删的情况怎么办？多重继承怎么处理？（金龙飞）
3、关联映射模式
3.1一对一关联模式：在关联两端各加一列。
3.2一对多关联模式：和3.1一样。如果多这端是有序的，还需加入一列表示序号。
3.3多对多关联模式：将关联单独作一个表。
3.4组合关联模式：注意级联式删除。
3.5反演关联模式：关联两端指向相关的类型，和普通关联一样。
3.6成对关联模式：关联记录两个类间的关系，用交集类表示关联，表示成一个单独的表，每个关联对应一个表，用外键表示它们间的关系。
3.7关联上的OCL需要分析成对应的存储过程代码。
3.8保证关联的cardinality也需要分析成对应的存储过程代码。
4、引用映射模式
在UML中不存在的MOF特征，指属性是声明为引用类型的实例。用存储过程实现。
)
批量操作 （orm 不实用）
Sql 与orm
存储过程（编译完的）
存储过程就是已经编译好的、优化过的放在数据库服务器中的一些SQL语句；可供应用程序直接调用。使用存储过程有以下几个优点：
1、执行速度比普通的SQL语句快
再运行存储过程前，数据库已对其进行了语法和句法分析，并给出了优化执行方案。这种已经编译好的过程可极大地改善SQL语句的性能。 由于执行SQL语句的大部分工作已经完成，所以存储过程能以极快的速度执行。
2、便于集中控制
当企业规则变化时，只需要在数据库的服务器中修改相应的存储过程，而不需要逐个的在应用程序中修改，应用程序保持不变即可，这样就省去了修改应用程序工作量。
3、可以降低网络的通信量
4、保证数据库的安全性和完整性
通过存储过程不仅可以使没有权限的用户在控制之下间接地存取数据库，保证数据的安全；而且可以使相关的动作在一起发生，从而可以维护数据库的完整性。
5、灵活性
存储过程可以用流控制语句编写，具有很强的灵活性，可以完成复杂的判断和运算，可以根据条件执行不通SQL语句。
存储过程的语法：
CREATE PROC [ EDURE] procedure_name [ ; number ]
[ { @parameter data_type }
[ VARYING ] [= default ] [ OUTPUT ]
] [ ,...n ]
[ WITH
{ RECOMPILE | ENCRYPTION | RECOMPILE ,ENCRYPTION } ]
[ FORREPLICATION ]
ASsql_statement [ ...n ]
****其中：[] 表示可选
参数解释：
procedure_name
新存储过程的名称。过程名必须符合标识符规则，且对于数据库及其所有者必须唯一。有关更多信息，请参见使用标识符。
要创建局部临时过程，可以在 procedure_name 前面加一个编号符 (#procedure_name)，要创建全局临时过程，可以在 procedure_name 前面加两个编号符 (##procedure_name)。完整的名称（包括 # 或 ##）不能超过 128 个字符。指定过程所有者的名称是可选的。
;number
是可选的整数，用来对同名的过程分组，以便用一条 DROP PROCEDURE 语句即可将同组的过程一起除去。例如，名为 orders 的应用程序使用的过程可以命名为 orderproc;1、orderproc;2 等。DROP PROCEDURE orderproc 语句将除去整个组。如果名称中包含定界标识符，则数字不应包含在标识符中，只应在 procedure_name 前后使用适当的定界符。
@parameter
过程中的参数。在 CREATE PROCEDURE 语句中可以声明一个或多个参数。用户必须在执行过程时提供每个所声明参数的值（除非定义了该参数的默认值）。存储过程最多可以有 2.100 个参数。
使用 @ 符号作为第一个字符来指定参数名称。参数名称必须符合标识符的规则。每个过程的参数仅用于该过程本身；相同的参数名称可以用在其它过程中。默认情况下，参数只能代替常量，而不能用于代替表名、列名或其它数据库对象的名称。有关更多信息，请参见 EXECUTE。
data_type
参数的数据类型。所有数据类型（包括 text、ntext 和 image）均可以用作存储过程的参数。不过，cursor 数据类型只能用于 OUTPUT 参数。如果指定的数据类型为 cursor，也必须同时指定 VARYING 和 OUTPUT 关键字。有关 SQL Server 提供的数据类型及其语法的更多信息，请参见数据类型。
说明 对于可以是 cursor 数据类型的输出参数，没有最大数目的限制。
VARYING
指定作为输出参数支持的结果集（由存储过程动态构造，内容可以变化）。仅适用于游标参数。
default
参数的默认值。如果定义了默认值，不必指定该参数的值即可执行过程。默认值必须是常量或 NULL。如果过程将对该参数使用 LIKE 关键字，那么默认值中可以包含通配符（%、_、[] 和 [^]）。
OUTPUT
表明参数是返回参数。该选项的值可以返回给 EXEC[UTE]。使用 OUTPUT 参数可将信息返回给调用过程。Text、ntext 和 image 参数可用作 OUTPUT 参数。使用 OUTPUT 关键字的输出参数可以是游标占位符。
n
表示最多可以指定 2.100 个参数的占位符。
{RECOMPILE | ENCRYPTION | RECOMPILE, ENCRYPTION}
RECOMPILE 表明 SQL Server 不会缓存该过程的计划，该过程将在运行时重新编译。在使用非典型值或临时值而不希望覆盖缓存在内存中的执行计划时，请使用 RECOMPILE 选项。
ENCRYPTION 表示 SQL Server 加密 syscomments 表中包含 CREATE PROCEDURE 语句文本的条目。使用 ENCRYPTION 可防止将过程作为 SQL Server 复制的一部分发布。
说明 在升级过程中，SQL Server 利用存储在 syscomments 中的加密注释来重新创建加密过程。
FOR REPLICATION
指定不能在订阅服务器上执行为复制创建的存储过程。.使用 FOR REPLICATION 选项创建的存储过程可用作存储过程筛选，且只能在复制过程中执行。本选项不能和 WITH RECOMPILE 选项一起使用。
AS
指定过程要执行的操作。
sql_statement
过程中要包含的任意数目和类型的 Transact-SQL 语句。但有一些限制。
n
是表示此过程可以包含多条 Transact-SQL 语句的占位符。
一个简单的存储过程：
CREATE PROCEDURE dbo.select_all AS
select * from my_test
多媒体服务器
缓存
多媒体服务器:用户将数据转换成信息，并把信息送到需要者手中的装置。
编辑本段功能：
可以捕获、处理、管理和传递多媒体信息：文本、图像、音频和视频。作为像Ａ.Ｂ.Ｃ这样的用户，必须适应各种形式（例如：书面报告、购货订单、发货单、录像带）信息的激增，他们必须能有效而得力地管理这些信息，以改进盈亏底钱。很多发展趋势正在向一处会聚，以便使商业计算用户从信息中获得越来越多的东西。
编辑本段未来趋势：
电子数据交换（ＥＤＩ）的出现、作为公用事业的电缆与电信提供商的新作用以及其它趋势都使许多公司开始探索使用信息的新方法，并将多种新的信息，例如音频、视频和动画等综合运用到这些组织机构中。这些用户不断增加的需求将促使他们需要一种多媒体服务器——一种能捕获、处理和管理多种信息，并将其传递到全公司内的任何用户，甚至可传递到像厂商与供应商这样的公司外的用户中去的信息服务器。
编辑本段特点：
多媒体服务器将自动进行数据捕获和运算，接收表数据、文本和图像以及音频和视频。它将启动一个机构的全部应用软件，利用可获得的信息进行事务处理、检索和发送与接收消息。此外，多媒体服务器还必须是一个强有力的企业系统，它提供连续可利用性，保持数据的完整性，并具有先进的保密性。多媒体服务器便于用户访问系统中的全部信息。
多媒体服务器的应用潜力超出了商业团体的范围，其对于更好地访问大容量存储的各种数据的需求是显而易见的。多媒体服务器可使像按需提供录像和联机目录这样的应用软件发挥效用，这些应用软件要求大容量存储并迅速传递到家庭中的许多并行用户。这些类型的应用软件奠定了大型通信与电缆公司及多媒体企业中几个最新联盟的基础。
编辑本段问题：
由于全世界的电缆和电信厂商不断地安装越来越多的宽带光缆，因此，极大地扩大了通过可定制的视频产品向单个用户或通过提供信息和服务分配网向商业用户分配信息的容量。问题通常是如何对这些新的信息服务的提供进行管理。
Ghost
端口映射
图片多
交互量大
逻辑多
数据量大
后台有服务
顶级域名
二级域名
在游戏中最消耗资源的是聊天系统
应用程序服务器上
Web 服务器
Int 4 字节
Char 2
Web app
基于本地
Sendmessages （window）
Socket 2 qq
远程
Socket
Self-hostedservice
数据库服务器
媒体服务
Jsonp
Ajax
异步操作（多线程）
Rss iframe div
& 位运算 +
&& 逻辑运算 支持保留操作
Xml 解析 DOM
使用代理模式
通过js来实现跨域性能不好
Web 服务器
数据库服务器
Js不能直接访问数据库，但是可以使用代理模式
Odata
Open data service
http://www.odata.org/
生产者
OData的生产者，揭露其数据使用OData协议的服务。
下面我们收集了关键OData的生产者的清单，这将继续增长OData的生态系统。
如果您创建或知道没有列出的OData生产者可以肯定的，让我们知道。
| 可以公开的OData服务的应用程序 |
|
| SharePoint 2010中 |
2010年的版本，你在SharePoint得到的数据可以通过OData协议，这使得SharePoint开发人员的API相当简单操纵。 |
| IBM WebSphere的 |
在IBM WebSphere eXtreme Scale的REST数据服务支持OData的。 |
| 微软SQL Azure |
如果你有一个SQL Azure数据库帐户，你可以很容易地通过一个简单的配置门户公开的OData饲料。您可以选择验证或匿名访问，并根据权限授予指定的SQL Azure数据库用户公开不同的OData的意见。 |
| Windows Azure表存储 |
Windows Azure表OData的端点中暴露的表的形式提供可伸缩，可用，耐用的结构化存储。 |
| SQL Server报表服务 |
微软SQL Server 2008 R2 Reporting Services中可以公开的数据作为OData的报告。 |
| 构建自己的 |
使用的OData的SDK，您可以添加到您的应用程序支持为OData的。 |
| 2011年的Microsoft Dynamics CRM |
最新版本可让您使用的OData查询 |
| GeoREST |
GeoREST是分发地理空间数据网络为中心的框架。它允许基于REST的基于特征的空间数据源，包括完整的编辑功能的访问，通过MapGuide的服务器或直接通过FDO。 |
| 2011年支持SDL Tridion |
支持SDL Tridion是一个网站内容管理解决方案，内容服务组件现在支持的OData |
| Webnodes的CMS |
Webnodes CMS是企业质量ASP.NET CMS的一个独特的语义内容技术。Webnodes最近增加了OData的支持。了解更多详情，请点击此处。 |
| Telerik OpenAccess的ORM |
Telerik在2010年年中发布了LINQ的实现是简单的使用和生产领域模型非常快。内置的LINQ实现的企业级Telerik OpenAccess的ORM上，让您轻松建立一个通过几个简单的步骤，使用的OpenAccess的可视化设计器和数据服务向导的OData的饲料。欲了解更多信息，请访问www.telerik.com / OData的 |
| Sitefinity CMS由Telerik |
由Telerik Sitefinity CMS主机的OData服务。功能强大的API，任何开发人员可以从CMS公开的任何信息，将通过一个自定义的OData服务。欲了解更多信息，请访问 |
| Telerik TeamPulse |
Telerik TeamPulse Silverlight客户端使用WCF数据服务与数据库进行交互，更具体地说，通过使用开放数据协议，这是一种流行的方式，从各种来源，包括公开的信息，但不仅限于关系数据库，文件系统，内容管理系统和传统的网站。 |
| tm2o - OData的主题地图提供商 |
TM2O - 这是一个通用的OData主题地图供应商。内部tm2o利用OData4J |
| OData的为的Team Foundation Server 2010 Beta版 |
到Team Foundation Server 2010的一个扩展，它允许您浏览TFS数据使用OData协议 |
| SAP NetWeaver的网关 |
SAP NetWeaver的网关（以前称为“项目网关”）是一种技术，它提供了一个简单的方式连接设备，环境和平台，基于市场的标准SAP软件。它提供了连接到SAP应用的SAP知识的利用OData的基于REST服务的需要没有使用任何编程语言或模型。 |
| Savigent软件催化剂XM |
开放数据协议提供各种现成的，现成的数据挖掘和商业智能工具容易获得催化剂XM™工作流执行历史，揭露从催化剂XM™的制造智能基于浏览器和移动客户端是一个理想的选择。催化剂XM服务器管理器提供了一个数据源生成器，它允许用户配置是动态创建的，通过开放数据协议提供数据访问的虚拟表。 |
| RemObjects数据摘要 |
一个完整的多层数据库应用程序框架，支持插入发布的数据，选择，更新和删除通过OData的。NET，单声道（Linux和OS X的）和Delphi的服务器库 |
| 现场的OData服务 |
||
| Netflix公司 |
OData的Netflix公司通过完整的目录标题。 |
浏览... |
| vanGuide |
一个社会的温哥华打开数据地图。收集的数据显示，从停车场到饮水机的服务。 |
浏览... |
| 温哥华街停车场 |
公开温哥华路边停车收费信息。 |
浏览... |
| 开放政府数据倡议 |
OGDI是一个不断增加的来自美国政府机构的数据。 |
浏览... |
| 开放科学数据倡议 |
检查和调查的基础上OGDI又使用Azure服务平台，使其更容易发布和使用了来自政府机构的科学数据的多种。 |
浏览... |
| 埃德蒙顿市开放数据目录 |
从埃德蒙顿市的公共数据。 |
浏览... |
| OData的测试服务 - 只读 |
这项服务是专门设计的OData在只读模式引入。 |
浏览... |
| OData的测试服务 - 读/写 |
这项服务是专门介绍在读写模式下（有一些限制）的OData。 |
浏览... |
| 罗斯文服务 - 只读 |
这项服务在只读模式通过OData的公开著名的Northwind示例数据库。 |
浏览... |
| OData的网站数据 |
一个从OData.org公开信息 - OData的 - 像生产者和消费者的服务。 |
浏览... |
| Pluralsight |
Pluralsight培训目录现在是作为一个OData的饲料。 |
浏览... |
| 书呆子晚餐 |
书呆子晚餐是一个网站，帮助书呆子见面和交谈，这并不奇怪，它已通过OData的。 |
浏览... |
| FACEBOOK透视 |
这是一个消费的Facebook透视数据OData服务的公共预览 |
浏览... |
| Devexpress频道 |
Devexpress有大量的培训视频，现在可以通过OData的饲料。 |
浏览... |
| 的TechEd 2010 |
微软TechEd 2010年会议的数据。 |
浏览... |
| DBpedia |
一个社会的努力，从Wikipedia中提取结构化信息，并与现场查询服务OData的相互作用的全力支持，使这些信息在网络上提供。（OpenLink公司的Virtuoso供电）。 |
浏览... |
| 链接开放数据云缓存 |
后视镜和几十个互连的数据集，包括所有的data.gov，全力支持OData的相互作用。（OpenLink公司的Virtuoso供电）。 |
浏览... |
| 易趣 |
eBay现在暴露了其通过OData的目录 |
浏览... |
| twitpic |
twitpic现在公开通过OData的图片，用户评论等 |
浏览... |
| Nuget |
Nuget是一个Visual Studio扩展，使得它易于安装和更新开放源码库和工具，在Visual Studio。 |
浏览... |
| 的Windows Live |
现在，您可以使用的OData客户端，谈谈您的Windows Live资源（照片，联系人，状态等）的REST端点现在的OData端点。 |
浏览... |
| Windows Azure的市场DataMarket |
Windows Azure的市场DataMarket允许生产者向消费者出售总理的数据，使用OData的。 |
浏览... |
| 微软的Pinpoint |
微软的Pinpoint市场公开其使用的OData数据 - 更多详情即将推出 |
浏览... |
| 堆栈溢出 |
对于程序员的Q＆A |
浏览... |
| 元堆栈溢出 |
问答关于堆栈溢出，服务器故障和超级用户 |
浏览... |
| 服务器故障 |
Q＆A为系统管理员和IT专业人员 |
浏览... |
| 超级用户 |
电脑爱好者和电力用户的Q＆A |
浏览... |
| 公共交通数据社区 |
从美国各地的交通运输机构的各种地下数据的收集。有关详细信息，请参阅开发人员文档。 |
浏览... |
| INETA直播 |
INETA现场OData的饲料，提供广大用户组艺术库的访问。 |
浏览... |
| Telerik电视 |
Telerik的目录库，视频，标签和系列 |
浏览... |
| LogMyTime |
项目时间跟踪软件和自由职业者小到中等队。 |
浏览... |
| Proagora |
Proagora是一个网站，可让您寻找就业机会，企业和专家。 |
浏览... |
| 2010年微软的PDC |
通过OData的暴露有关的所有会话/扬声器等微软的PDC 2010的信息 |
浏览... |
| 梅迪辛哈特市打开数据目录 |
从加拿大梅迪辛哈特市公共数据 |
浏览... |
| Research.microsoft.com [RMC]的OData |
RMC的OData是资产research.microsoft.com发表的元数据查询的版本，如出版物，录像，项目，并下载。 |
浏览... |
英语，数学，数据结构，数据库原理
数据库服务器与多媒体服务器
数据库服务器
Relation 关系
Performance 性能
聚集索引
非聚集索引
Concarency 并发
数据库同步的应用
后来者优先
先来者优先
客服端 服务器端
在orm 中
通过反射机制
批量操作
高速
三七分
70% ORM
30% sql 语句（
50% jdbc apo.net
50% 存储过程（stored-procedure）
已经编译完的程序
数据密集型的访问时才使用存储过程
）
解释与编译
IIS
启用web 缓存机制
设计模式
外观模式
工厂模式（数据库的链接）
单件模式