• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

从今天开始我将学习axis的经验以笔记的形式共享给大家希望能对大家的工作有所帮助。

     相信大家对webservice有一定的了解我在这里就不再复述webservice的一些基本概念。

axis1.3是soap1.2协议的一个实现框架。在工作中我们可以方便的通过axis进行webservice的开发。

废话少说，我们开始安装axis.

     我们可以从axis的官方网站上下载(http://ws.apache.org/axis/).解压缩axis-bin-1_3.zip。在lib中包含axis必须使用的jar包。docs中包含axis的文档，通常使用用户指南就可以解决大部分问题。samples中包含很多webservice的例子，以后会对这些例子进行进一步讲解。webapps文件夹中包含了一个axis web application你可以直接把他部署到tomcat中，然后在这个axis应用上发布你的webservice,发布成功后就可以调用了。build文件夹用来存放用ant编译的axis安装包的classes文件。

     第一个步骤：安装axis.( Axis 1.3,tomcat 5.028, jdk 1.42)

copy  axis-bin-1_3安装包下webapps文件夹中的axis目录到tomcat的webapps下发布你的axis应用。重新启动tomcat.访问http://localhost:8080/axis 。这时就会出现axis的欢迎画面.进入Validation链接以检查axis所使用的jar包是否全都存在。如果不存在就会显示一下画面：

下面我们来进行调用。首先进入客户端源代码所在位置，也可以将源代码所在目录添加到classpath中

（C:\Documents and Settings\y41yang\Desktop\software\axis-bin-1_3\axis-1_3;）：

然后输入java samples.userguide.example2.CalcClient -p8080 add 2 5

 这时如果结果为Got result : 7 则说明axis安装成功！如果失败了请检查classpath设置，

是否将所有用到的jar文件加入classpath中。到这里axis就已经安装成功了！

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

　Convert的使用方法：

　　格式：

Convert(data_type,expression[,style])

　　说明：此样式一般在时间类型(datetime,smalldatetime)与字符串类型(nchar,nvarchar,char,varchar)相互转换的时候才用到.

　　例子：

SELECT Convert(varchar(30),getdate(),101) now

　　结果为

　　now

　　09/15/2001

　　style数字在转换时间时的含义如下：

Style(2位表示年份)	Style(4位表示年份)	输入输出格式
0	100	mon dd yyyy hh：miAM(或PM)
1	101	mm/dd/yy
2	102	yymmdd
3	103	dd/mm/yy
4	104	ddmmyy
5	105	ddmmyy
6	106	dd mon yy
7	107	mon dd,yy
8	108	hh：mm：ss
9	109	mon dd yyyy hh：mi：ss：mmmmAM(或PM)
10	110	mmddyy
11	111	yy/mm/dd
12	112	yymmdd
13	113	dd mon yyyy hh：mi：ss：mmm(24小时制)
14	114	hh：mi：ss：mmm(24小时制)
20	120	yyyymmdd hh：mi：ss(24小时制)
21	121	yyyymmdd hh：mi：ss：mmm(24小时制)

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

**
 *Output: 
Original contents of al: C A E B D F 
Modified list backwards: F+ D+ B+ E+ A+ C+ 

 */

import java.util.ArrayList;
import java.util.Iterator;
import java.util.ListIterator;

public class MainClass {
  public static void main(String args[]) {
    ArrayList<String> al = new ArrayList<String>();

    al.add("C");
    al.add("A");
    al.add("E");
    al.add("B");
    al.add("D");
    al.add("F");

    System.out.print("Original contents of al: ");
    Iterator<String> itr = al.iterator();
    while (itr.hasNext()) {
      String element = itr.next();
      System.out.print(element + " ");
    }
    System.out.println();

    ListIterator<String> litr = al.listIterator();
    while (litr.hasNext()) {
      String element = litr.next();
      litr.set(element + "+");
    }

    // Now, display the list backwards.
    System.out.print("Modified list backwards: ");
    while (litr.hasPrevious()) {
      String element = litr.previous();
      System.out.print(element + " ");
    }
  }
}

http://demo.q139.cn/Code/JavaAPI/java.util/ArrayListiterator.htm

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

张利：清华大学、北京大学、中共中央党校特邀教授、著名战略营销专家，企业经营模式研究专家

标力大厦省建行四楼

笔记：

营销不是专业

战胜不复－－－别自以为是，要自以为非

君子务本，本定而道生。

企业经营目的不等于利润；有价值的产品肯定是有其特色的。

赚钱 生意的三要素

 a 能否产生现金？－－现金流大于一切

 b 能否获得一个很好的资产收益率（资产收益率＝利润率×周转率 宏图三胞具有每年50次的资金周转率）

c 能否持续的成长

经营企业三原则：现金流第一，利润第二，规模第三

不赌博

高必以下为基，贵必以贱为本！－－老子    

追求市场份额：细分市场第一 区域市场第一 做隐形冠军

做小池塘里的大鱼，不做大池塘里的小鱼

马太效应：强者占有资源，赢家通吃

能提高效益的手段就是最有效的管理手段（对政府腐败是比较有效的管理手段）

营销起源于竞争 标杆营销适合于小企业

产品＋服务－>解决方案

顾客不一定是上帝，谁稀缺谁上帝。

没有选择余地的客户是最忠诚的  台湾“7－11”小商店

《韩非子.奸劫弑臣》

顾客价值＝解决问题的功能/购买代价

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

一尺之捶，日取其半，万世不竭！

7.2 对象和类的粒度

7.2.1 CPU难题

        处理有包容关系的类，用继承机制还是聚合机制？

        多态性的机制可以大量减少条件判断语句的重复。

       继承和动态绑定

  7.2.2 继承的粒度

类的定义：类是对象的抽象，是一系列既有共性又有个性的对象的高度概括。

对象的共性和个性是相对的而不是绝对的。

对继承粒度问题的认识：

1.必须基于需求来确定继承的粒度。如果提取对象的某一个共性对于我们要解决的问题没有任何帮助，或只有很小的帮助，那就没有必要因为提取共性而增加继承数的复杂度。

2.对象的某些共性更适合于用属性而不是用新的基类和派生类来表达。

3.利用类和对象是模拟现实世界的手段而不是目的。我们不能为了提取类而提取类。我们最终的目的是最大限度地实现代码复用，提高软件质量。因此，如果不能达到复用代码地目的，就没有必要再提取新地类了。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

天下莫大于秋毫之末，而大山为小......

6.2.2 架构分析的作用

 a、架构分析为软件定义了科学的结构和规则，可以有效地控制软件地复杂性，易于理解、实现和管理

架构模式描述了软件系统基本的结构组织策略

设计要求：

层和层之间的耦合应该尽可能地松散

级别相同、指责类似的元素应该北组织到同一层中；

复杂的模块应该被继续分解为粒度更细的层或子系统；

应尽量将可能发生变化的元素封装到一个层中，这样，变化发生时我们只要改变受影响的层就可以了

每一层只调用下一层提供的功能服务，决不能调用上一层提供的功能服务，避免循环依赖

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

不，我不想要自由；我只要条出路，向左或是向右，到哪儿都行。

5.2 面向对象的思维方式：围绕对象和类来分析、设计软件系统

5.3 面向对象分析

   面向对象分析的主要任务就是根据用户需求，建立一个准确的、完整的、一致的系统模型。这个过程的输入是软件的功能性需求。该过程产生三个分析模型：

a、功能模型：把用户的功能性需求转化为开发人员和用户都能理解的一种表达方式，其结果就是我们此前谈到的用例模型

b、对象模型：通过对用例模型的分析，把系统分解成互相协作的分析类。一般情况下，我们通过类图和对象图来描述系统中所有对象、对象属性、及对象之间的相互关系。对象模型就是系统的静态模型

c、动态模型：描述系统的动态行为，一般用顺序图和协作图来描述系统中对象之间的交互关系

5.3.2 实体类和软件类

5.3.2.1 实体类 （Entity class）是应用领域中的核心类，一般是从现实世界中的实体对象归纳和抽象出来的，用于长期保存系统中的信息，以及提供针对这些信息的相关处理行为。一般情况下，实体类的对象实例和应用系统本身有着相同的生命周期

5.3.2.2 边界类和控制类

边界类（boundary class）：边界类是系统内的对象和系统外的参与者的联系媒体，外界的消息只能通过边界类的对象实例才能发送给系统

控制类（control class）：实体类和边界类之间的润滑剂，是从控制对象中归纳和抽象出来的，用于协调系统内边界类和实体类之间的交互

5.4

5.4.1 提取实体对象和实体类（物理或实在的对象；人的角色；组织；事件；地点；故则说明或事物描述；规则和策略）

5.4.2 提取属性

5.4.3 提取关系（“有……”，“是……的一部分”，“包含”，“包括”，“管理”，“报告”） 1：1； 1：m； m：n ；归纳关系

5.4.4 添加边界类

5.4.5 添加控制类

5.4.6 绘制类图

5.4.7 绘制顺序图

5.4.8 变化的需求

5.4.9 编制术语表

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

见山是山 见水是水；见山不是山，见水不是水；见山只是山，见水只是水；

GoF 《设计模式》

设计模式中蕴涵的面向对象设计原则和设计思路：

a、设计模式最根本的意图是适应需求变化

b、针对接口编程，而不是针对实现编程

c、优先使用聚合，而不是继承

4.3.6 设计模式的分类

a、按设计模式的目的分类（主要用来完成什么工作）：创建型模式（封装对象的创建过程）、结构型模式（处理类或对象的组织结构）、行为型模式（指导类和对象之间的交互以及职责分配关系）

b、按处理范围不同：类模式（处理类和派生类之间的继承关系）、对象模式（处理对象之间的组织关系）

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。
-- Christopher Alexander

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

GoF23 种设计模式

历史性著作《设计模式：可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式，创立了模式在软件设计中的地位。该书
四位作者被人们并称为Gang of Four （GoF），“四人组”，该书描述的23种经典设计模式又被人们称为GoF23 种设计模式。

由于《设计模式：可复用面向对象软件的基础》一书确定了设计模式的地位，人们通常所说的设计模式隐含地表示“面向对象设计模式”。
但这并不意味“设计模式”就等于“面向对象设计模式”，也不意味着GoF23种模式就表示了所有的“面向对象设计模式”。除了“面向对象设计模式”外，还有其他设计模式。除了GoF23 种设计模式外，还有更多的面向对象设计模式。

GoF23 种设计模式是学习面向对象设计模式的起点，而非终点；本培训课程的目标是让学员在建立在有效方法的基础上，掌握GoF23种设计模式。

设计模式与面向对象

面向对象设计模式解决的是“类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式几个方面。

面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”是那些可以满足“应对变化，提高复用”的设计。

面向对象设计模式描述的是软件设计，因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达，本课程基于C#语言，但实际上它适用于支持.NET框架的所有.NET语言，如Visual Basic.NET、C++/CLI等。

面向对象设计模式不像算法技巧，可以照搬照用，它是建立在对“面向对象”纯熟、深入的理解的基础上的经验性认识。掌握面向对象设计模式的前提是首先掌握“面向对象”！

从编程语言直观了解面向对象

各种面向对象编程语言相互有别，但都能看到它们对面向对象三大机制的支持，即： “封装、继承、多态”

– 封装，隐藏内部实现
– 继承，复用现有代码
– 多态，改写对象行为

使用面向对象编程语言（如C#），可以推动程序员以面向对象的思维来思考软件设计结构，从而强化面向对象的编程范式。

C#是一门支持面向对象编程的优秀语言，包括：各种级别的封装支持；单实现继承+多接口实现；抽象方法与虚方法重写。

但OOPL并非面向对象的全部

通过面向对象编程语言（OOPL）认识到的面向对象，并不是面向对象的全部，甚至只是浅陋的面向对象。

OOPL的三大机制“封装、继承、多态” 可以表达面向对象的所有概念，但这三大机制本身并没有刻画出面向对象的核心精神。换言之，既可以用这三大机制做出“好的面向对象设计”，也可以用这三大机制 做出“差的面向对象设计”。不是使用了面向对象的语言（例如C#），就实现了面向对象的设计与开发！因此我们不能依赖编程语言的面向对象机制，来掌握面向对象。

OOPL没有回答面向对象的根本性问题——我们为什么要使用面向对象？我们应该怎样使用三大机制来实现“好的面向对象”？ 我们应该遵循什么样的面向对象原则？

任何一个严肃的面向对象程序员（例如C#程序员），都需要系统地学习面向对象的知识，单纯从编程语言上获得的面向对象知识，不能够胜任面向对象设计与开发。

从一个示例谈起

示例场景：

我们需要设计一个人事管理系统，其中的一个功能是对各种不同类型的员工，计算其当月的工资——不同类型的员工，拥有不同的薪金计算制度。

结构化做法

1.获得人事系统中所有可能的员工类型
2.根据不同的员工类型所对应的不同的薪金制度，计算其工资
enumEmployeeType
{
Engineer;
Sales;
Manager;
…
}
// 计算工资程序
if ( type == EmployeeType.Engineer)
{
……
}
else if (type == Employeetype.Sales)
{
……
}

面向对象设计

1.根据不同的员工类型设计不同的类，并使这些类继承自一个Employee抽象类，其中有一个抽象方法GetSalary。
2.在各个不同的员工类中，根据自己的薪金制度，重写（override）GetSalary方法。
abstract class Employee
{
…
public abstract int GetSalary();
}
class Engineer: Employee
{
…
public override int GetSalary()
{
…
}
}
class Sales: Employee
{
…
public override int GetSalary()
{
…
}
}
// 显示工资程序
Employee e = emFactory.GetEmployee(id);
MessageBox.Show( e.GetSalary());

示例场景：

现在需求改变了……随着客户公司业务规模的拓展，又出现了更多类型的员工，比如钟点工、计件工……等等，这对人事管理系统提出了挑战——原有的程序必须改变。

结构化做法

几乎所有涉及到员工类型的地方（当然包括“计算工资程序”）都需要做改变……这些代码都需要重新编译，重新部署…….

面向对象做法

只需要在新的文件里增添新的员工类，让其继承自Employee抽象类，并重写GetSalary()方法，然后在EmployeeFactory.GetEmployee方法中根据相关条件，产生新的员工类型就可以了。其他地方（显示工资程序、Engineer类、Sales类等）则不需要做任何改变。

重新认识面向对象

对于前面的例子，从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小

从微观层面来看，面向对象的方式更强调各个类的“责任”，新增员工类型不会影响原来员工类型的实现代码——这更符合真实的世界，也
更能控制变化所影响的范围，毕竟Engineer类不应该为新增的“钟点工”来买单……

对象是什么？

– 从概念层面讲，对象是某种拥有责任的抽象。
– 从规格层面讲，对象是一系列可以被其他对象使用的公共接口。
– 从语言实现层面来看，对象封装了代码和数据。

有了这些认识之后，怎样才能设计“好的面向对象”？

– 遵循一定的面向对象设计原则
– 熟悉一些典型的面向对象设计模式

从设计原则到设计模式

针对接口编程，而不是针对实现编程

– 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。

优先使用对象组合，而不是类继承

– 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

封装变化点

– 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

使用重构得到模式——设计模式的应用不宜先入为主，一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发实践提倡的“Refactoring to Patterns ”是目前普遍公认的最好的使用设计模式的方法。

几条更具体的设计原则

单一职责原则（SRP）：

– 一个类应该仅有一个引起它变化的原因。

开放封闭原则（OCP）：

– 类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

Liskov 替换原则（LSP）:
– 子类必须能够替换它们的基类

. 依赖倒置原则（DIP）：

– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

接口隔离原则（ISP）：

– 不应该强迫客户程序依赖于它们不用的方法。

总结

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方 案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

深刻理解面向对象是学好设计模式的基础，掌握一定的面向对象设计原则才能把握面向对象设计模式的精髓，从而实现灵活运用设计模
式。

三大基本面向对象设计原则

– 针对接口编程，而不是针对实现编程
– 优先使用对象组合，而不是类继承
– 封装变化点

使用重构得到模式。敏捷软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

Part 1 层

层（layer）这个概念在计算机领域是非常了不得的一个概念。计算机本身就体现了一种层的概念：系统调用层、设备驱动层、操作系统层、CPU指令集。每个层都负责自己的职责。网络同样也是层的概念，最著名的OSI的七层协议。

层到了软件领域也一样好用。为什么呢？我们看看使用层技术有什么好处：

• 你使用层，但是不需要去了解层的实现细节。
• 可以使用另一种技术来改变基础的层，而不会影响上面的层的应用。
• 可以减少不同层之间的依赖。
• 容易制定出层标准。
• 底下的层可以用来建立顶上的层的多项服务。 当然，层也有弱点：
• 层不可能封装所有的功能，一旦有功能变动，势必要波及所有的层。
• 效率降低。

当然，层最难的一个问题还是各个层都有些什么，以及要承担何种责任。

典型的三层结构

三层结构估计大家都很熟悉了。就是表示（presentation）层, 领域（domain）层, 以及基础架构（infrastructure）层。

表示层逻辑主要处理用户和软件的交互。现在最流行的莫过于视窗图形界面（wimp）和基于html的界面了。表示层的主要职责就是为用户提供信息，以及把用户的指令翻译。传送给业务层和基础架构层。

基础架构层逻辑包括处理和其他系统的通信，代表系统执行任务。例如数据库系统交互，和其他应用系统的交互等。大多数的信息系统，这个层的最大的逻辑就是存储持久数据。

还有一个就是领域层逻辑，有时也被叫做业务逻辑。它包括输入和存储数据的计算。验证表示层来的数据，根据表示层的指令指派一个基础架构层逻辑。

领域逻辑中，人们总是搞不清楚什么事领域逻辑，什么是其它逻辑。例如，一个销售系统中有这样一个逻辑：如果本月销售量比上个月增长10％，就要用红色标记。要实现这个功能，你可能会把逻辑放在表示层中，比较两个月的数字，如果超出10％，就标记为红色。

这样做，你就把领域逻辑放到了表示层中了。要分离这两个层，你应该现在领域层中提供一个方法，用来比较销售数字的增长。这个方法比较两个月的数字，并返回boolean类型。表示层则简单的调用该方法，如果返回true，则标记为红色。

例子

层技术不存在说永恒的技巧。如何使用都要看具体的情况才能够决定，下面我就列出了三个例子：

例子1：一个电子商务系统。要求能够同时处理大量用户的请求，用户的范围遍及全球，而且数字还在不断增长。但是领域逻辑很简单，无非是订单的处理，以及和库存系统的连接部分。

这就要求我们1、表示层要友好，能够适应最广泛的用户，因此采用html技术；2、支持分布式的处理，以胜任同时几千的访问； 3、考虑未来的升级。

例子2：一个租借系统。系统的用户少的多，但是领域逻辑很复杂。这就要求我们制作一个领域逻辑非常复杂的系统，另外，还要给他们的用户提供一个方便的输入界面。这样，wimp是一个不错的选择。

例子3：简单的系统。非常简单，用户少、逻辑少。但是也不是没有问题，简单意味着要快速交付，并且还要充分考虑日后的升级。因为需求在不断的增加之中。

何时分层

这样的三个例子，就要求我们不能够一概而论的解决问题，而是应该针对问题的具体情况制定具体的解决方法。这三个例子比较典型。

第二个例子中，可能需要严格的分成三个层次，而且可能还要加上另外的中介（mediating）层。例3则不需要，如果你要做的仅是查看数据，那仅需要几个server页面来放置所有的逻辑就可以了。

我一般会把表示层和领域层/基础架构层分开。除非领域层/基础架构层非常的简单，而我又可以使用工具来轻易的绑定这些层。这种两层架构的最好的例子就是在VB、PB的环境中，很容易就可以构建出一个基于SQL数据库的windows界面的系统。

这样的表示层和基础架构层非常的一致，但是一旦验证和计算变得复杂起来，这种方式就存在先天缺陷了。

很多时候，领域层和基础架构层看起来非常类似，这时候，其实是可以把它们放在一起的。可是，当领域层的业务逻辑和基础架构层的组织方式开始不同的时候，你就需要分开二者。

更多的层模式

三层的架构是最为通用的，尤其是对IS系统。其它的架构也有，但是并不适用于任何情况。

第一种是Brown model [Brown et al]。它有五个层：表示层（Presentation），控制/中介层（Controller/Mediator），领域层（Domain）, 数据映射层（Data Mapping）, 和数据源层（Data Source）。它其实就是在三层架构种增加了两个中间层。控制/中介层位于表示层和领域层之间，数据映射层位于领域层和基础架构层之间。

表示层和领域层的中介层，我们通常称之为表示-领域中介层，是一个常用的分层方法，通常针对一些非可视的控件。例如为特定的表示层组织信息格式，在不 同的窗口间导航，处理交易边界，提供Server的facade接口（具体实现原理见设计模式）。最大的危险就是，一些领域逻辑被放到这个层里，影响到其 它的表示层。

我常常发现把行为分配给表示层是有好处的。这可以简化问题。但表示层模型会比较复杂，所以，把这些行为放到非可视化的对象中，并提取出一个表示-领域中介层还是值得的。

Brown ISA

表示层 表示层

控制/中介层 表示-领域中介层

领域层 领域层

数据映射层 数据库交互模式中的Database Mapper

数据源层 基础架构层

领域层和基础架构层之间的中介层属于本书中提到的Database Mapper模式，是三种领域层到数据连接的办法之一。和表示-领域中介层一眼，有时候有用，但不是所有时候都有用。

还有一个好的分层架构是J2EE的架构，这方面的讨论可以见『J2EE核心模式』一书。他的分层是客户层（Client），表示层（Presentation），业务层（Business ），整合层（Integration），资源层（Resource）。差别如下：

J2EE核心 ISA

客户层 运行在客户机上的表示层

表示层 运行在服务器上的表示层

业务层 领域层

整合层 基础架构层

资源层 基础架构层通信的外部数据

微软的DNA架构定义了三个层：表示层（presentation），业务层（business），和数据存储层（data access），这和我的架构相似，但是在数据的传递方式上还有很大的不同。

在微软的DNA中，各层的操作都基于数据存储层传出的SQL查询结果集。这样的话，实际上是增加了表示层和业务层同数据存储层之间的耦合度。DNA的记录集在层之间的动作类似于Data Transfer Object。

Part 2 组织领域逻辑

要组织基于层的系统，首要的是如何组织领域逻辑。领域逻辑的组织有好几种模式。但其中最重要的莫过于两种方法：Transation Script和Domain Model。

选定了其中的一种，其它的都容易决定。不过，这两者之间并没有一条明显的分界线。所以如何选取也是门大学问。一般来说，我们认为领域逻辑比较复杂的系统可以采用Domain Model。

Transation Script就是对表示层用户输入的处理程序。包括验证和计算，存储，调用其它系统的操作，把数据回传给表示层。用户的一个动作表示一个程序，这个程序可 以是script，也可以是transation，也可以是几个子程序。在例子1中，检验，在购物车中增加一本书，显示递送状态，都可以是一个 Transation Script。

Domain Model是要建立对应领域名词的模型，例如例1中的书、购物车等。检验、计算等处理都放到领域模型中。

Transation Script属于结构性思维，Domain Model属于OO思维。Domain Model比较难使用，一旦习惯，你能够组织更复杂的逻辑，你的思想会更OO。到时候，即使是小的系统，你也会自然的使用Domain Model了。

但如何抉择呢？如果逻辑复杂，那肯定用Domain Model：如果只需要存取数据库，那Transation Script会好一些。但是需求是在不断进化的，你很难保证以后的需求还会如此简单。

如果你的团队不善于使用Domain Model，那你需要权衡一下投入产出比。另外，即使是Transation Script，也可以做到把逻辑和基础架构分开，你可以使用Gateway。

对例2，毫无疑问要使用Domain Model。对例1就需要权衡了。而对于例3，你很难说它将来会不会像例2那样，你现在可以使用Transation Script，但未来你可能要使用Domain Model。所以说，架构的决策是至关紧要的。

除了这两种模式，还有其它中庸的模式。Use Case Controller就是处于两者之间。只有和单个的用例相关的业务逻辑才放到对象中。所以大致上他们还是在使用Transation Script，而Domain Model只是Database Gateway的一组集合而已。我不太用这种模式。

Table Module是另一个中庸模式。很多的GUI环境依托于SQL查询的返回结果。你可以建立内存中的对象，来把GUI和数据库分开来。为每个表写一个模块，因此每一行都需要关键字变量来识别每一个实例。

Table Module适用于很多的组件构建于一个通用关系型数据库之上，而且领域逻辑不太复杂的情况。Microsoft COM 环境，以及它的带ADO.NET的.NET环境都适合使用这种模式。而对于Java，就不太适用了。

领域逻辑的一个问题是领域对象非常的臃肿。因为对象的行为太多了，类也就太大了。它必须是一个超集。这就要考虑哪些行为是通用的，哪些不是，可以由其它的类来处理，可能是Use Case Controller，也可能是表示层。

还有一个问题，复制。他会导致复杂和不一致。这比臃肿的危害更大。所以，宁可臃肿，也不要复制。等到臃肿为害时再处理它吧。

选择一个地方运行领域逻辑

我们的精力集中在逻辑层上。领域逻辑要么运行在Client上，要么运行在Server上。

比较简单的做法是全部集中在Server上。这样你需要使用html的前端以及web server。这样做的好处是升级和维护都非常的简单，你也不用考虑桌面平台和Server的同步问题，也不用考虑桌面平台的其它软件的兼容问题。

运行在Client适合于要求快速反应和没有联网的情况。在Server端的逻辑，用户的一个再小的请求，也需要信息从Client到Server绕一圈。反应的速度必然慢。再说，网络的覆盖程度也不是说达到了100％。

对于各个层来说，又是怎么样的呢？

基础架构层：一般都是在Server啦，不过有时候也会把数据复制到合适的高性能桌面机，但这是就要考虑同步的问题了。

表示层在何处运行取决于用户界面的设计。一个Windows界面只能在Client运行。而一个Web界面就是在Server运行。也有特别的例子，在桌面机上运行web server的，例如X Server。但这种情况少的多。

在例1中，没有更多的选择了，只能选在Server端。因此你的每一个bit都会绕一个大圈子。为了提高效率，尽量使用一些纯html脚本。

人们选用Windows界面的原因主要就是需要执行一些非常复杂的任务，需要一个合适的应用程序，而web GUI则无法胜任。这就是例2的做法。不过，人们应该会渐渐适应web GUI，而web GUI的功能也会越来越强大。

剩下的是领域逻辑。你可以全部放在Server，也可以全部放在Client，或是两边都放。

如果是在Client端，你可以考虑全部逻辑都放在Client端，这样至少保证所有的逻辑都在一个地方。而把web server移至Client，是可以解决没有联网的问题，但对反应时间不会有多大的帮助。你还是可以把逻辑和表示层分离开来。当然，你需要额外的升级和维护的工作。

在Client和Server端都具有逻辑并不是一个好的处理办法。但是对于那些仅有一些领域逻辑的情况是适用的。有一个小窍门，把那些和系统的其它部分没有联系的逻辑封装起来。 领域逻辑的接口

你的Server上有一些领域逻辑，要和Client通信，你应该有什么样的接口呢？要么是一个http接口，要么是一个OO接口。

http接口适用于web browser，就是说你要选择一个html的表示层。最近的新技术就是web service，通过基于http、特别是XML进行通信。XML有几个好处：通信量大，结构好，仅需一次的回路。这样远程调用的的开销就小了。同时，XML还是一个标准，支持平台异构。XML又是基于文本的，能够通过防火墙。

虽然XML有那么多的好处，不过一个OO的接口还是有它的价值的。hhtp的接口不明显，不容易看清楚数据是如何处理的。而OO的接口的方法带有变量和名字，容易看出处理的过程。当然，它无法通过防火墙，但可以提供安全和事务之类的控制。

最好的还是取二者所长。OO接口在下，http接口在上。但这样做就会使得实现机制非常的复杂。

Part 3 组织web Server

很多使用html方式的人，并不能真正理解这种方式的优点。我们有各种各样好用的工具，但是却搞到让程序难以维护。在web server上组织程序的方式大致可以分为两种：脚本和server page。

脚本方式就是一个程序，用函数和方法来处理http调用。例如CGI脚本和java servlet。它和普通的程序并没有什么两样。它从web页面上获得html string形态的数据，有时候还要做一些表达式匹配，这正是perl能够成为CGI脚本的常用语言的原因。

而Java servelet则是把这种分析留给程序员，但它允许程序员通过关键字接口来访问信息，这样就会少一些表达式的判断。这种格式的web server输出是另一种html string，称为response，可以通过流数据来操作。

糟糕的是流数据是非常麻烦的，因此就导致了server page的产生，例如PHP，ASP，JSP。

server page的方式适合回应（response）的处理比较简单的情况。例如“显示歌曲的明细”，但是你的决策取决于输入的时候，就会比较杂乱。例如“通俗和摇滚的显示格式不同”。

脚步擅长于处理用户交互，server page擅长于处理格式化回应信息。所以很自然的就会采用脚本处理请求的交互，使用server page处理回应的格式化。这其实就是著名的MVC（Model View Controller）模式中的view/controller的处理。

应用Model View Controller模式首要的一点就是模型要和web服务完全分离开来。使用Transaction Script或Domain Model模式来封装处理流程。

接下来，我们就把剩余的模式归入两类模式中：属于Controller的模式，以及属于View的模式。

View模式

View这边有三种模式：Transform View，Template View和Two Step View。Transform View和Template View的处理只有一步，将领域数据转换为html。Two Step View要经过两步的处理，第一步把领域数据转换为逻辑表示形式，第二步把逻辑表示转换为html。

两步处理的好处是可以将逻辑集中于一处，如果只有一步，变化发生时，你就需要修改每一个屏幕。但这需要你有一个很好的逻辑屏幕结构。如果一个web应用有很多的前端用户时，两步处理就特别的好用。例如航空订票系统。使用不同的第二步处理，就可以获得不同的逻辑屏幕。

使用单步方法有两个可选的模式：Template View，Transform View。Template View其时就是把代码嵌入到html页面中，就像现在的server page技术，如ASP，PHP，JSP。这种模式灵活，强大，但显得杂乱无章。如果你能够把逻辑程序逻辑在页面结构之外进行很好的组织，这种模式还是有它的优点的。

Transform View使用翻译方式。例如XSLT。如果你的领域数据是用XML处理的，那这种模式就特别的好用。

Controller模式

Controller有两种模式。一般我们会根据动作来决定一项控制。动作可能是一个按钮或链接。所这种模式就是Action Controller模式。

Front Controller更进一步，它把http请求的处理和处理逻辑分离开来。一般是只有一个web handle来处理所有的请求。你的所有的http请求的处理都由一个对象来负责。你改变动作结构的影响就会降到最小。

http://www.uml.org.cn/sjms/200601241.htm

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

思想的真正客观性应该是：思想不仅是我们的思想，同时也是事物的自身，或对象性的东西的本质

衡量软件的设计质量：可读性、可复用性、可扩展性、可维护性

面向对象的基本概念：

封装：对现实世界的模拟，反映某一种事物的共性

 继承 ：遗传

多态性 ：静态多态性，动态多态性

抽象

面向对象的基本原则：

 开闭原则：一个模块对扩展应是开放的，对修改应是关闭的

完全替换原则：派生类应该能完全替换掉基类

依赖倒置原则：依赖于抽象，而不要依赖于具象

非循环依赖原则：包和包之间不能有循环依赖关系

只实现你真正需要的东西，不要去实现你认为需要的东西

不要重复自己：任何代码都只出现一次

保持简化的设计

为人写代码，而不是为机器写代码

3.4.4 面向对象的开发过程

a、面向对象分析：根据用户需求，建立准确、完整、一致的系统模型，该模型描述软件需要解决的问题是什么，我们称之为分析模型

b、架构分析：宏观上考虑一个软件系统应该如何组织，以及该软件系统需要满足的设计约定、规则、和模式等

c、面向对象设计：以分析模型作为输入，把分析模型转化成描述如何解决问题的系统模型，得出完整的解决方案

d、编码：实�