博客园_达叔开发

dynamics ax 2009 distinct实现及数组集合

2011-09-14T08:42:00Z

1 通过分组实现distinct
　　select ItemType,GoodsName from tableA order by ItemType,GoodsName group by ItemType,GoodsName
            where tableA.ItemType == '传入的值';
　　采用上述SQL就可得到distict后的值，如果要取出数据后再进行distinct可以采用2中介绍的Set类；
2 数组集合
　　注意：
　　　　1 List、Map、Struct、Array提供了可序列化的pack和unpack功能，可以减少RPC次数，提高速度；
　　　　2 如果设置了key的类型，存入不同类型如：string-->int,会自动存默认值(0)进去;
[Set 类]
Set类中所有值得类型都相同；Set会自动排序并且所有值都是唯一的，插入重复的值时，Set会自动忽略。
　　 set.Add("");
　　while(set.MoveNext())
　　{
  　　　　set.current();
　　}
[List 类]
List类同Set类的区别：
可添加相同值，可选择插入前面或者后面；
在List的顺序是添加时的顺序，不会自动排序；
　　list.Add("");
　　while(list.MoveNext())
　　{
  　　　　list.current();
　　}
[Map 类]
Map类保存键值对，键不能重复，当插入相同键时，用新值代替旧值,键自动排序。
　　map.insert(1,"");
　　while(map.MoveNext())
　　{
  　　　　map.currentKey(),map.currentValue();
　　}
[Struct 类]
Struct 类相当于没有方法的类，可拥有不同数据类型字段，但只能有一行记录。
　　struct.value("ID",1);
　　struct.value("name","");
　　struct.add("","");
　　for(i = 1; i <= struct.fields();i++)
　　{
　　　　 struct.fieldname(i),struct.valueIndex(i);
　　}
[Array 类]
Array 类使用类实现数组，可容纳任意数据类型，包括对象和表变量；索引值从1开始，相同的索引值新值替换旧值。
　　array.value(1,"");
　　for(i = 1; i <= array.lastIndex();i ++)
　　{
  　　　　array.value(i);
　　}
[Stack 类]
Stack 类是后进先出（LIFO）的数据结构类型，只能放置容器类型Container,添加和删除都从顶部开始。
　　stack.push(Container1);
　　conpeek(stack.pop(),1);
[StackBase 类]
StackBase 类同Stack 类，除了它可以放置任意类型。
　　stackbase.push("");
　　stackbase.pop();

本文链接

dynamics ax 2009 字段类似的表绑定界面注意

2011-09-01T08:54:00Z

* 设字段类似的表

tableA: ItemType GoodsName

tableB: ItemType GoodsName Size

如果先完成了对tableA的增删改界面frmTableA,我们可能用"重复"的方法得到相同的界面frmTableB,在此基础上修改更加快速.

但是需要注意的是,如果把DataSource里面tableA的Name直接修改为tableB界面上所有控件的字段绑定将不再正确,需要重新调整;

正确的做法是:修改DataSource里面tableA的Table属性为tableB,再修改Name属性。

本文链接

dynamics Ax 2009 实现 union 效果

2011-08-31T08:38:00Z

Ax中多表关联仅提供Inner Join/Outer Join/Exist join/Not Exist join,而么有union,可以通过Query来实现.

例如 Sql:

select ItemType,GoodsName from table1 where TransDate between g_DateB and g_DateE
union
select ItemType,GoodsName from table2 where TransDate between g_DateB and g_DateE

1 实现[ from table1 ]
    qbd = query.addDataSource(tableNum(table1));
2 实现[ select ItemType,GoodsName ]
    qbd.addSelectionField(fieldnum(table1,ItemType));
    qbd.addSelectionField(fieldnum(table1,GoodsName));
3 实现[ where TransDate between g_DateB and g_DateE ]
  qbd.addRange(fieldnum(table1,TransDate)).value(strfmt("%1..%2", g_DateB,g_DateE));
4 实现[ union ]
    query.queryType(QueryType::Union);

代码:
Query query;
    QueryRun qr;
    QueryBuildDataSource qbd;
    QueryBuildDataSource qbd2;
    Table1 newTable;

qbd = query.addDataSource(tableNum(table1));
    qbd.addSelectionField(fieldnum(table1,ItemType));
    qbd.addSelectionField(fieldnum(table1,GoodsName));
    qbd.addRange(fieldnum(table1,TransDate)).value(strfmt("%1..%2", g_DateB,g_DateE));

qbd2 = query.addDataSource(tablenum(table2));
    qbd2.addSelectionField(fieldnum(table2,ItemType));
    qbd2.addSelectionField(fieldnum(table2,GoodsName));
    qbd2.addRange(fieldnum(table2,TransDate)).value(strfmt("%1..%2", g_DateB,g_DateE));

    qbd2.addRange(fieldnum(table2,RecId)).
            value(strfmt("((%1 > %2) || (%3 > %4) || (%5 > %6))",
            fieldstr(table2,Qty),queryValue(0),
            fieldstr(table2,Weight),queryValue(0),
            fieldstr(table2,Volume),queryValue(0)));// OR Condition

query.queryType(QueryType::Union);
    qr = new QueryRun(query);
    while(qr.next())
    {
     newTable = qr.get(tableNum(table1));
     //do something...
  }

本文链接

.net 发展历程

2011-05-12T06:50:00Z

.net版本发展历程：

版本	版本号	发布日期	Visual Studio	windows集成
1.0	1.0.3705.0	2002-02-13	Visual Studio .NET
1.1	1.1.4322.573	2003-04-24	Visual Studio .NET 2003	Windows Server 2003
2.0	2.0.50727.42	2005-11-07	Visual Studio 2005
3.0	3.0.4506.30	2006-11-06		Windows Vista, Windows Server 2008
3.5	3.5.21022.8	2007-11-19	Visual Studio 2008	Windows 7, Windows Server 2008 R2
4.0	4.0.30319.1	2010-04-12	Visual Studio 2010

.NET Framework 各个版本之间的关系图：

C#2.0新特性：

一、泛型（Generic）
概述：
引入泛型绝对是C#2.0的最大的新特性。通过“参数化类型”实现一份代码操作多种数据类型。泛型的优点是更好的类型安全；更好的复用；更高的效率和更清晰的约束。但说实在，除了一些通用的数据结构，集合类和通用算法外，使用到泛型的地方还不多。而且System.Collections.Generic中的类也很够用了。基本没写过自己的泛型类。
语法点：
语法方面主要是使用在类型名称后面加入“<T>”来传入类型参数。涉及泛型类型继承的一条规则是“封闭类（所有类型都已确定）不能继承开放类（含有未确定类型）”。同时可以使用where来添加对作为参数的类型的约束。具体有四种：基类约束、接口约束、构造器约束和值/引用类型约束。最后特别提醒，delegate也是一种类型，别忘了泛型委托。

二、泛型方法（Generic Method）
概述：
泛型方法即在方法声明中包含类型参数。其实属泛型的内容。但泛型方法可以用在一般类中。
语法点：
重载（overload）的时候注意，约束不成为方法签名的一部分。而重写（override），约束是会被默认继承的。

三、匿名方法（Anonymous Method）
概述：可以直接将代码赋给委托。在进行委托实例化时可以省略掉委托类型。代码示例如下：
myButton.Click += delegate {//代码}
myButton.Click += myClick;
感觉就是一种语法的简化。从代码的可维护性来说还是不用为好。但又确实能使一些代码简洁一点。看团队的决定吧。
语法点：
要注意外部变量的生存周期会一直延长到委托实例引用结束。尽量避免使用。

四、迭代器（Iterator）
概述：
严格来说只是简化迭代器的构造罢了。或者说简化了创建可以用于foreach的枚举集合的工作。通过引入关键字yield来实现。再不用太多的关心IEnumerator了。直接在类中实现GetEnumerator()然后在for循环中用yield return就可以了。
语法点：
可以用yield break来停止迭代。

五、局部类（Partial Class）
概述：
就是允许通过关键字partial将一个类写在多个cs文件中。最大的用处可能就是将IDE自动生成的代码分开吧。大家都留意到VS05中的自动生成的代码都到designer.cs中去了吧。
语法点：
在不同部分定义中，Attribute和Interface是累加的。当然要保证基类的唯一。而abstract和sealed是部分使用，整个类生效。语义类型访问修饰符要保持一致。

六、可空类型（Nullable Type）
概述：
其实是一个泛型类型。System.Nullable<T>,T必须为值类型。并且通过“？”来作一个语法的简化。用一句代码说明就是：
int? x = null;
引入NullableType获得的启示是，.Net的ORMapping可以做得更好了。
语法点：
使用HasValue属性判断是否为null。

七、静态类（Static Class）
概述：
可以声明一个static class。该class不能被继承不能被实例化，只能包含静态成员。相当于sealed abstract。用途可以用作全局函数。另外Singleton模式的实现更方便了。
语法点：
不能有constructor，不能有实例成员，不能再使用sealed abstract修饰。不能继承其他类和实现任何interface。成员不能使用protected修饰符。

八、属性访器访问修饰符
概述：
可以额外对get、set中的其中一个属性访问其使用一个访问修饰符。用途可以说是更灵活的封装吧。
语法点：
只能在get、set的一个中使用。接口中的属性访问器不能同样不能带有访问修饰符。索引器可以使用。

九、命名空间别名限定符
概述：可以使用双冒号“::”使用一个命名空间的别名。如
using sc=System.Collection;
那么使用的时候就可以写成sc::ArrayList()了。
作用是更方便的调用不同命名空间下的同名类性。

就写这主要的九点，其他还有的一些C#2.0的新特就不写了。因为离开发的使用更远了。总的来说除了泛型，2.0真的不是有很多的有用的变化。或许更应关注Framework的发展吧。以上的是我个人的归纳，写得不详细。如果真的想了解语法各位看官可要自己再查了。2.0已远处，C#3.0已经来了，一股LINQ的学习热潮到了。继续前行，学好新技术，更关键是用好新技术。

--------------------------------------------------------------------------------------------------

C#3.0新特性:

1：隐式类型的本地变量和数组

2：对象初始值设定项

3：集合初始值设定项

4：自动实现属性

5：匿名类型

6：扩展方法

7：分部方法定义

8：Lambda 表达式

关键字（var）

1：var可以用局部变量声明不可以用于字段可以应用于for、foreach、using语句中

2：var关键字不能包含自身对象或者集合初始化器，但可以经过new的新表达式

例：var result;//编译错误

var result=result+1;//编译错误

var result={1,2,3};//编译错误

3：var是推断类型，不是显示类型

4：var关键字指示编译器根据初始化语句右侧的表达式推断变量的类型

5：推断类型可以是内置类型、匿名类型、用户定义类型、.NET Framework 类库中定义的类型或任何表达式

注：var关键字并不意味着“变体”，也不表示该变量时松散类型化变量或后期绑定变量。它只是表示由编译器确定和分配最适合的类型

var 使用的场景

1：局部变量

例：var i = 5;

2：在for初始化语句

例：for(var i = 1; i < 10; ++i)

3：在foreach初始化语句

例：foreach(var item in list)

4：在using语句

例：using(var file = new StreamReader("C:\"))

一：隐式类型的本地变量和数组

注：隐形数组使用var关键字和数组初始化器创建。元素的数据类型必须能够隐式转换为同一数据类型，并且不能为空(null)

1：没有在初始化语句的左侧隐式类型的数组使用方括号

2：支持交错数组，不支持多维数组

例：var a = new [] {1,2,3} //一维数组

var b = new []

{

new [] {1,2,3},

new [] {5,6}

}; //交错数组

二：对象初始值设定项

注：对象初始化器由一系列成员对象组成，其对象必须初始化，用逗号间隔，使用{}封闭

1.NET 2.0写法：

User userInfo = new User();

userInfo.ID = “zhuxing”;

userInfo.Name = “czx”;

userInfo.Age= 22;

2.NET 3.5写法：

User userInfo = new User() {ID = “zhuxing”, Name = “czx”, Age=22};

注：嵌套复杂属性类型

User userInfo = new User()

{

ID=“zhuxing”,

Name=“czx”,

Address =new Address()

{

Province=“FuJian”,

City=“ningde”

}

};

1：可以和构造函数一起使用,并且构造函数初始化先于对象初始化器执行

2：允许部分赋值

3：允许给internal 成员赋值

public class user

{

public String Name { get; set; }

public String Age { get; set; }

private Int32 test = 25;

internal Int32 test2;

}

public class Program

{

static void Main(string[] args)

{

user person = new user { Name = "张三", Age = "男", test2 = 20 };

Console.WriteLine("{0},{1},{2}",person.Name, person.Age, person.test2);

Console.ReadLine();

}

//和构造函数一起使用

public class user

{

public String Name { get; set; }

public Int32 Age { get; set; }

private Int32 test = 25;

internal Int32 test2;

public user(Int32 Age)

{

this.Age = Age;

}

public class Program

{

static void Main(string[] args)

{

user person = new user(20) { Name = "张三", Age = 22, test2 = 20 };

Console.WriteLine("{0},{1},{2}",person.Name, person.Age, person.test2);

Console.ReadLine();

}

三：集合初始值设定项

注：

1：集合初始化器由一系列集合对象组成，用逗号间隔，使用{}封闭。

2：集合初始化器会对初始化器中的元素进行按序调用ICollection<T>.Add(T)方法

例如：List<int> number=new List<int>{1,2,3,4,5};

//集合初始化器

public class parame

{

public String Name { get; set; }

public Int32 Age { get; set; }

}

public class Program

{

static void Main(string[] args)

{

IList<parame> people = new List<parame>()

{

new parame{ Name = "张三", Age = 18},

new parame{ Name = "李四", Age = 20}

};

foreach (var i in people)//var 是3.0特有的

{

Console.WriteLine("{0},{1}", i.Name, i.Age);

}

Console.ReadLine();

}

四：自动实现属性

1、.NET2.0下写User类：

public class User

{

private string id;//用户ID

public string ID

{

get{return id;}

Set {id=value;}

}

private string name;//用户名称

public string Name

{

get{return name;}

set{name=value;}

}

2、.NET 3.5下写User类：

public class User

{

public string ID{get;set;}

public string Name{get;set;}

}

注：在VS2008像以上写法，编译器自动会为类中生成一个私有变量，并对这个变量实现公开的getter和setter访问器

五：匿名类型

注：使用new操作符和匿名对象初始化器创建一个新的对象，该对象是匿名类型的对象。

如：

var role=new{ID=“zhuxing”,Name=“czx”};

等同于:

class _Anonymous1

{

private string id;

public string ID

{

get{return id;}

set{id=value;}

}

private string name;

public string Name

{

get{return name;}

set{name=value;}

}

1：匿名类型提供了一种方便的方法，可以用来将一组只读属性封装到单个对象中，而无需首先显示定义一个类型

2：类型名由编译器生成，并且不能在源代码级使用

3：这些属性的类型由编译器判定

4：匿名类型通常用在查询表达式select子句中，以便返回源序列化对象的属性子集

5：匿名类型是使用new运算符和对象初始值设定项创建的

6：匿名类型是由一个或多个只读属性组成的类类型。不允许包含其他种类的类型

（如方法或事件）

7：匿名类型是直接从对象派生的引用类型。尽管应用程序无法访问匿名类型，但编译器仍会为其提供一个名称。

8：如果两个或更多个匿名类型以相同的顺序具有相同数量和种类的如果两个或更多个匿名类型以相同的顺序具有相同数量和种类的属性，则编译器会将这些匿名类型视为相同的类型，并且它们共享编译器生成的相同类型信息。匿名类型具有方法范围 – 匿名类型具有方法范围。

9：匿名类型不能像属性一样包含不安全类型。

10：由于匿名类型上的 Equals 和 GetHashCode 方法是根据属性的由于匿名类型上的Equals 和 GetHashCode 方法是根据属性的Equals 和 GetHashcode 定义的，因此仅当同一匿名类型的两个

注：查询表达式经常使用匿名类型，而这些类型只能使用对象初始值设定项进行初始化

例：var productInfos = from p in products

select new { p.ProductName, p.UnitPrice };

创建匿名类型时重命名字段：

select new {p.ProductName, Price = p.UnitPrice};

六：扩展方法

1、扩展方法的优势

1.1、允许开发人员往一个现有的CLR类型的公开契约(contract)中添加新的方法，而不用生成子类或者重新编译原来的类型。

1.2、可以通过使用实例方法语法调用的静态方法，对现有类功能进行扩充，从而使该类型的实例具有更多的方法（功能）。

1.3、允许我们在不改变源代码的情况下扩展（即添加不能修改）现有类型中的实例方法

1.4、有助于把今天动态语言中流行的对duck typing的支持之灵活性，与强类型语言之性能和编译时验证融合起来

2、扩展方法的要点

2.1、本质为将实例方法调用在编译期改变为静态类中的静态方法调用，具备静态方法的功能

2.2、作用域是整个namespace可见的，并且可以通过using namespace来导入其它命名空间中的扩展方法。

2.3、优先级：现有实例方法优先级最高，其次为最近的namespace下的静态类的静态方法，最后为较远的namespace下的静态类的静态方法

七：分部方法定义

注：处理一些轻量级的事件

八：Lambda 表达式

1、格式如下：(参数列表)=>表达式或语句块；

例： var str=list.FindAll(s=>s.indexof(“mzc”)>=0);

2、参数列表可以是显示或者隐式类型，在显式列表中，每个参数的类型是显式指定的，在隐式列表中，参数的类型由Lambda表达式出现的语境自动推断类型。

例：

(x, y) => x * y;//多参数，隐式类型=>表达式

x => x * 10;//单参数，隐式类型=>表达式

x => { return x * 10; }; //单参数，隐式类型=>语句块

(int x) => x * 10;//单参数，显式类型=>表达式

(int x) => { return x * 10; };//单参数，显式类型=>语句块

( ) => Console.WriteLine(); //无参数

表达式树

注：表达式树允许像处理数据一样对Lambda表达式进行读取和改写，比如我们在动态查询的时候经常应用到

------------------------------------------------------------------------------------------------------

C#3.5新特性：

Visual Studio 2008和.NET 3.5是建立在.NET2.0核心的基础之上，C# 3.0新语言特性在.NET2.0基础上进行了改进，这些改进的功能可以大大简化我们编写程序。在此为了自己学习记录下来，并与大家分享

.NET 3.5的新特性包括：

自动属性(Auto-Implemented Properties)

隐含类型局部变量(Local Variable Type Inference)

匿名类型(Anonymous Types)

对象与集合初始化器(Object and Collection Initializers)

扩展方法(Extension Methods)

Lambda表达式和Lambda表达式树 (Lambda Expression and Lambda Expression Trees)

LINQ，语言级集成查询（Language INtegrated Query）

自动属性(Auto-Implemented Properties)

自动属性可以避免原来这样我们手工声明一个私有成员变量以及编写get/set逻辑，在VS2008中可以像下面这样编写一个类，编译器会自动地生成私有变量和默认的get/set 操作。你也可以分别定义get和set的"protected"等访问级别。

在.Net2.0框架下，我们可以这样写一个User类：

public class User

{

private int _id;

private string _name;

private int _age;

public int Id

{

get { return _id; }

set { _id = value; }

}

public string Name

{

get { return _name; }

set { _name = value; }

}

public int Age

{

get { return _age; }

set { _age = value; }

}

}现在，可以这样简化：

public class User

{

public int Id { get; set; }

public string Name { get; set; }

public int Age { get; set; }

}

我们可以利用VS.NET提供的ildasm进行反编译，可以发现.NET帮我定义了私有变量，在此不再赘言。

隐含类型局部变量(Local Variable Type Inference)

C#3.0引进了var这个新关键字，在声明局部变量时可用于替代原先的类型名，即当一个变量声明标识为var类型并且该范围域中没有var名称类型存在，那么这个声明就称为隐含类型局部变量。如下（等同于//后面的显式声明）：

var i = 5;//int

var j = 23.56;//double

var k = "C Sharp";//string

var x;//错误

var y = null;//错误

var z = { 1, 2, 3 };//错误

注意事项：

必须对var声明的变量赋值，因为C#中的var并不等同于VB于Javascript中的var,后者中的var为一种变量类型，而在C#中var并不是一种类型，它只用来隐式的声明变量，而你定义的变量类型由编译器判断；

Var声明的变量不能赋null;

Var只能声明局部变量；

不允许,改变var变量的类型

Var x = 100;

X = "Hello world!"

由此可知，var的变量也是强类型的变量，具有安全性。

匿名类型(Anonymous Types)

匿名类型允许定义行内类型，无须显式定义类型。常和var配合使用来声明匿名类型。

var p1 = new { Id = 1, Name = "tony", Age = 21 };//属性也不需要申明

var p2 = new { Id = 2, Name = "dream", Age = 21 };

var p3 = new { Id =3 , age = 21, Name = "tony"}

p1 = p2;//p1,p2结构相同，可以互相赋值 ,p1与p3不是相同的对象，所以使用匿名类型时我们尽量将具有相同属性的变量，属性的顺序保持一致。

在这里编译器会认为p1,p2相当于：

public class SomeType

{

public int Id { get; set; }

public string Name { get; set; }

public int Age { get; set; }

}那么数组怎么定义呢？使用"new[]"关键字来声明数组，加上数组的初始值列表。像这样：

var intArray = new[] { 2, 3, 5, 6 };

var strArray = new[] { "Hello", "World" };

var anonymousTypeArray = new[]

{

new { Name = "tony", Age = 21 },

new { Name = "dream", Age = 22 }

};

var a = intArray[0];

var b = strArray[0];

var c = anonymousTypeArray[1].Name;

可以使用new关键字调用匿名初始化器创建一个匿名类型的对象。

匿名类型直接继承自System. Object。

匿名类型的成员是编译器根据初始化器推断而来的一些读写属性。

对象初始化器 (Object Initializers) ：

.NET2.0框架中的类型非常依赖于属性。当生成对象实例和使用新的类型时，在.Net2.0时候我们像这样写：

User user = new User();

user.Id = 1;

user.Name = "tony";

user.Age = 22;在VS2008中，编译器会自动地生成合适的属性setter代码，使得原来几行的属性赋值操作可以在一行完成。我们可以这样简化：像这样，对象初始化器由一系列成员对象组成，其对象必须初始化，用逗号间隔，使用{}封闭。

User user = new User { Id = 1, Name = "tony", Age = 21 };又例如，我把二个人加到一个基于泛型的类型为User的List集合中：

List<User> user = new List<User>{

new User{Id=1,Name="tony",Age=21},

new User{Id=2,Name="dream",Age=12},

};

如果有相同名字和类型的两个对象初始化器将会产生相同的实例，可以相互赋值。例如：

User user = new User { Id = 1, Name = "tony", Age = 21 };

User user2 = new User { Id = 2, Name = "tony", Age = 12 };

user = user2;

除了在初始化类时设置简单的属性值外，对象初始化器特性也允许我们设置更复杂的嵌套(nested)属性类型。例如我们可以在上面定义的User类型同时拥有一个属于School类型的叫"School"的属性：

User user = new User

{

Id = 1,

Name = "tony",

Age = 21,

School = new School

{

City = "Beijing",

Name = "BTBU"

}

};

集合初始化器(Collection Initializers)：

集合初始化器由一系列集合对象组成，用逗号间隔，使用{}封闭。

集合初始化器可以简化把几个对象一起添加到一个集合，编译器会自动为你做集合插入操作。例如我把七个数加到一个基于泛型的类型为int的List集合中

List<int> num = new List<int> { 0, 1, 2, 6, 7, 8, 9 };对象与集合初始化器要点

对象初始化器实际上利用了编译器对对象中对外可见的字段和属性进行按序赋值。

对象初始化器允许只给一部分属性赋值，包括internal访问级别

对象初始化器可以结合构造函数一起使用，并且构造函数初始化先于对象初始化器执行。

集合初始化器会对初始化器中的元素进行按序调用ICollection<T>.Add(T)方法,所以只有具有Add方法的类才可以使用这种方法添加一个元素，例如ArrayList等，例如HashTable,字典等就不支持这种添加方式，因为其存在key,value两个值。

注意对象初始化器和集合初始化器中成员的可见性和调用顺序。

对象与集合初始化器同样是一种编译时技术。

扩展方法(Extension Methods)

往往我们需要对CLR类型进行一些操作，但苦于无法扩展CLR类型的方法，只能创建一些helper方法，或者继承类。我们来修改上面的User类：

public class User

{

public int Id { get; set; }

public string Name { get; set; }

public int Age { get; set; }

public string Read()

{

return "Id:" + Id + "姓名:" + Name + "年龄:" + Age;

}

}然后调用

var user = new { Id = 1, Name = "tony", Age = 21 };

var str = user.Read();现在有了扩展方法就方便多了。

扩展方法允许开发人员往一个现有的CLR类型的公开契约(contract)中添加新的方法，而不用生成子类或者重新编译原来的类型。扩展方法有助于把今天动态语言中流行的对duck typing的支持之灵活性，与强类型语言之性能和编译时验证融合起来。

扩展方法是可以通过使用实例方法语法调用的静态方法。效果上，使得附加的方法扩展已存在类型和构造类型成为可能。他可以对现有类功能进行扩充，从而使该类型的实例具有更多的方法（功能）。

扩展方法允许我们在不改变源代码的情况下扩展（即添加不能修改）现有类型中的实例方法。

扩展方法给我们一个怎样的思路呢？我们一步一步做一下！

首先声明扩展方法：通过指定关键字this修饰方法的第一个参数。注意扩展方法仅可声明在静态类中。扩展方法具备所有常规静态方法的所有能力，可以使用实例方法语法来调用。接着就可以调用扩展方法了。下面通过一个具体的实例分析一下：

例如我们要检查一个字符串变量是否是合法的电子邮件地址？在.Net2.0框架下像这样：

var email = "tony_wanghongchen@hotmail.com";

if (EmailValidator.IsValid(email))

{

Response.Write("tony提示:这是一个正确的邮件地址");

}而使用扩展方法的话，我可以添加"IsValidEmailAddress()"方法到string类本身中去，该方法返回当前字符串实例是否是个合法的字符串。

if (email.IsValidEmailAddress())

{

Response.Write("tony提示:这是一个正确的邮件地址");

}我们是怎么把这个IsValidEmailAddress()方法添加到现有的string类里去的呢？先定义一个静态类，再定义"IsValidEmailAddress"这个静态的法来实现的。

public static class Extensions//静态类

{

public static bool IsValidEmailAddress(this string s)

//静态方法和this

{

Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$");

return regex.IsMatch(s);

}

}注意，上面的静态方法在第一个类型是string的参数变量前有个"this"关键词，这告诉编译器，这个特定的扩展方法应该添加到类型为"string"的对象中去。然后在IsValidEmailAddress()方法实现里，我可以访问调用该方法的实际string实例的所有公开属性/方法/事件，取决于它是否是合法电子邮件地址来返回true/false。

扩展方法不仅能够应用到个别类型上，也能应用到.NET框架中任何基类或接口上。即可用于整个.NET框架丰富的可组合的框架层扩展。

扩展方法要点

扩展方法的本质为将实例方法调用在编译期改变为静态类中的静态方法调用。事实上，它确实拥有静态方法所具有的所有功能。

扩展方法的作用域是整个namespace可见的，并且可以通过using namespace来导入其它命名空间中的扩展方法。

扩展方法的优先级：现有实例方法优先级最高，其次为最近的namespace下的静态类的静态方法，最后为较远的namespace下的静态类的静态方法。

扩展方法是一种编译时技术，注意与反射等运行时技术进行区别，并慎重使用。

Lambda表达式和Lambda表达式树 (Lambda Expression and Lambda Expression Trees)

Lambda表达式

我们从"所有字符串查找包含tony子字符串"说起。在C# 2.0中，匿名方法允许我们以内联的方式来实现委托实例，它提供强大的函数式编程语言，但是标记显得相当的冗长和带有强制性。我们使用C# 2.0 中的匿名方法查找，代码如下：

var inString = list.FindAll(delegate(string s)

{ return s.Indexof("tony") >= 0; });现在可以使用C# 3.0带来的Lambda表达式允许我们使用一种更接近人的思维、更自然的方式来实现类似于匿名方法同样的效果，看下面的代码多么简洁：

var inString = list.FindAll(s => s.Indexof("tony") >= 0);Lambda表达式格式：(参数列表)=>表达式或语句块

具体意义：定义Lambda接受参数列表，运行表达式或语句块返回表达式或语句块的值传给这个参数列表。

Lambda表达式参数类型可以是隐式类型或显式类型。在显式列表中，每个参数的类型是显式指定的，在隐式列表中，参数的类型由Lambda表达式出现的语境自动推断类型。

Lambda表达式的参数列表可以有一个或多个参数，或者无参数。在有单一的隐型参数的lambda表达式中，圆括号可以从参数列表中省略。

例如：

(x, y) => x * y;//多参数，隐式类型=>表达式

x => x * 10;//单参数，隐式类型=>表达式

x => { return x * 10; }; //单参数，隐式类型=>语句块

(int x) => x * 10;//单参数，显式类型=>表达式

(int x) => { return x * 10; };//单参数，显式类型=>语句块

() => Console.WriteLine(); //无参数下面看这个例子：

在前面的帖子中，我们写了一个User类及增加了2个人，接下来，我们使用由LINQ提供的新的Where和Average方法来返回集合中的人的一个子集，以及计算这个集合中的人的平均年龄：

List<User> user = new List<User>{

new User{Id=1,Name="tony",Age=21},

new User{Id=2,Name="tony",Age=22},

};

//获取特定人时所用的过滤条件，p参数属于User类型

var results = user.Where(p => p.Name == "tony").ToList();

//用User对象的Age值计算平均年龄

var average = user.Average(p => p.Age);

LINQ，语言级集成查询（Language INtegrated Query）

经过了最近 20 年，面向对象编程技术（ object-oriented (OO) programming technologies ）在工业领域的应用已经进入了一个稳定的发展阶段。程序员现在都已经认同像类（classes）、对象（objects）、方法（methods）这样的语言特性。考察现在和下一代的技术，一个新的编程技术的重大挑战开始呈现出来，即面向对象技术诞生以来并没有解决降低访问和整合信息数据（accessing and integrating information）的复杂度的问题。其中两个最主要访问的数据源与数据库（ database ）和 XML 相关。

LINQ 提供了一条更常规的途径即给 .Net Framework 添加一些可以应用于所有信息源（ all sources of information ）的具有多种用途（ general-purpose ）的语法查询特性（ query facilities ），这是比向开发语言和运行时（ runtime ）添加一些关系数据（ relational ）特性或者类似 XML 特性（ XML-specific ）更好的方式。这些语法特性就叫做 .NET Language Integrated Query (LINQ) 。

包含 DLinq 和 XLinq

C#3.0 LINQ 查询语法

首先来看一个很简单的LINQ查询例子，查询一个int 数组中小于5的数字，并按照大小顺序排列：

class Program

{

static void Main(string[] args)

{

int[] arr = new int[] { 8, 5, 89, 3, 56, 4, 1, 58 };

var m = from n in arr where n < 5 orderby n select n;

foreach (var n in m)

{

Console.WriteLine(n);

}

Console.ReadLine();

}

上述代码除了LINQ查询语法外，其他都是我们所熟悉的语法，而LINQ查询语法跟SQL查询语法很相似，除了先后顺序。

Q：为何 LINQ 查询语法是以 from 关键字开头的，而不是以 select 关键字开头的？select 开头这种写法跟SQL的写法更接近，更易懂呀？

A：简单来说，为了IDE的智能感知（InteliSence）这个功能，select 关键字放在后面了。

编程语言以 select 开头写LINQ查询语法不是没出现过，你如果使用过2005年的VB9 CTP 版本，那时候VB9的LINQ查询语法就是 select 关键字在前面，但是 select 关键字在前面，在做智能感知（InteliSence）时候就很头大。经过微软IDE组的权衡，确定了把 from 关键字放在最前面。

我们再来看一个稍稍复杂的LINQ查询：

在我们罗列的语言字符串中，我们希望按照字符长短，分类罗列出来，实现代码如下：

static void Main(string[] args)

{

string [] languages = {"Java","C#","C++","Delphi","VB.net","VC.net","C++ Builder","Kylix","Perl","Python"};

var query = from item in languages

orderby item

group item by item.Length into lengthGroups

orderby lengthGroups.Key descending

select lengthGroups;

foreach (var item in query)

{

Console.WriteLine("strings of length ",item.Key);

foreach (var val in item)

{

Console.WriteLine(val);

}

Console.ReadLine();

}

其中的 into 关键字表示将前一个查询的结果视为后续查询的生成器，这里是跟 group by一起使用的。

LINQ中的Group by不要跟 SQL 中的Group by 混淆，SQL 由于是二维结构，Group by 的一些逻辑受二维结构的约束，无法象 LINQ 中的Group by 这么灵活。

-------------------------------------------------------------------------------------

简介
- C# 4.0
动态查找
- 类型
- 动态操作
- 运行时查找
- 示例
- 带有动态参数的重载解析
- 动态语言运行时
- 已知问题
命名参数和可选参数
- 可选参数
- 命名的和可选的实参
- 重载解析
互操作特性
- 动态引入
- 无PIA的编译
- ref 省略ref
- 已知问题
变性
- 协变性
- 逆变性
- 限制
COM Example COM示例
Relationship with Visual Basic 与Visual Basic的关系
资源

http://www.kuqin.com/dotnet/20081111/26639.html

本文链接

ibatis经验

2011-03-18T01:05:00Z

1.insert,update,delete 返回值
(1).insert 返回的为插入的主键值，但必须在配置文件中加入<selectKey/>
   如果主键值为String
<selectKey resultClass="string" keyProperty="id">
   SELECT @@IDENTITY AS ID
</selectKey>

   如果主键值为Int型
<selectKey resultClass="java.lang.Integer" keyProperty="id" >
   SELECT @@IDENTITY AS ID
</selectKey>
或者
<selectKey resultClass="int" keyProperty="id">
   SELECT @@IDENTITY AS ID
</selectKey>
注：@@IDENTITY只是SQL Server的写法，其他数据库也有相关的属性。

(2).Update,和Delete返回为修改数据影响的条数；
2.SQL模糊查询的两种方法
(1).如果是模糊查询，在关键字传入前加‘％’；例：String keyword=”%”+keyword+”%”;
(2).配置文件的写法： select name,sex from t_user where name like '%$name$%'
3.在ibatis的bean.xml配置文件中，日期的转换
<![CDATA[
select count( 1 ) from dbu_window where
(
( DATE_FORMAT( '$dateStartTemp$', '%Y-%m-%d' ) >= f_start_date and
    DATE_FORMAT( '$dateStartTemp$', '%Y-%m-%d' ) <= f_end_date )
or
( DATE_FORMAT( '$dateEndTemp$', '%Y-%m-%d' ) >= f_start_date and
    DATE_FORMAT( '$dateEndTemp$', '%Y-%m-%d' ) <= f_end_date ) )
]]>
4.$sql$即程序预定义sql语句的应用
java代码：String selSql = "select count(*) from `bbs_config`;";
     sqlMapClient.queryForObject( "execSelSqlStr" , selSql );
bean.xml文件：
<select id="execSelSqlStr" resultClass="int" parameterClass="string">
   <![CDATA[   $sql$   ]]>
</select>
5.ResultClass和ResultMap的区别
resultClass:可以把结果自动映射到相应的JAVA类中，但无法指定输出字段的类型，会对性能产生轻微的影响。
resultMap:可以预先定义resultMap元素，可以控制数据如何从结果集中取出，以及哪个属性匹配哪个字段，

parameterClass和parameterMap的区别
parameterClass属性值是JAVA类的全限定名，目的是限制输入参数的类型为指定的JAVA类，如果不指定，任何带有合适属性（get/set方法）的JAVA BEAN都可以作为输入参数
parameterMap:预先定义parameterMap的属性值，用于有次序的参数匹配JDBC符号
6.“#”和“$”的区别
“#” 为占为符，#在是用prepareStatement的?插入参数,$是文本替换
“$”为直接替换，但为出现SQL引入问题和性能上的影响，like,limit和表名的引入必须使用“$”
7.where 条件的组装
<isEqual>         比较属性值和静态值或另一个属性值是否相等
<idNotEqual>      比较属性值和静态值或另一个属性值是否不相等
<isGreaterThan>    比较属性值是否大于静态值或另一个属性值
<isGreaterEqual>   比较属性值是否大于等于静态值或另一个属性值
<isLessThan>      比较属性值是否小于静态值或另一个属性值
<isLessEqual>     比较属性值是否小于等于静态值或另一个属性值
<isNull>          检查属性是否为NULL
<isNotNull>       检查属性是否不为NULL
<isEmpty>        检查属性是否为NULL或空
<isNotEmpty>     检查属性是否不为NULL或不为空
<isPropertyAvailable>       检查是否存在该属性
<isNotPropertyAvailable>    检查是否不存在该属性
8.<![CDATA[ ]]>的含义
用了特殊字符的SQL语句(比如>，<)不能直接使用。必须用<![CDATA[ ]]>
9.ibatis自带缓存的运用
<cacheModel id=”person-cache” implementation=”LRU”>
   <flushInterval hours=”24”/>       //可以用hours/minutes/second
   <flushOnExecute   statement=”selectperson”/>    //需要缓存的方法，可以为多个
   <property name=”size” value=”1000”/>
</cacheModel>

缓存策略：
   LRU：最近最少使用
   MEMORY：适用于没有统一的对象重用模式，property的属性值必须是STRONG，
   SOFT，WEAK，这三个值分别对应于JVM不同内存reference类型。
   WEAK,大多数情况下，WEAK是最佳选择，缺省值就是WEAK，它能大大提高常用查询的性能，对于当前不被使用的查询数据，将被清除
   SOFT，在查询结果对象不被使用，可以减少内存不足的可能性
   STRONG，对查询的结果一直保留在内存中，可以使用在数据量很少或者静态数据的时
   FIFO：先进先出
   OSCACHE：配置oscache.properties
10.value的使用
假如没有必要写JAVA BEAN作为参数，可以直接使用基本类型，也可以直接传入参数值。如果是直接传入参数值就配置文件中必须写 #value#做为参数传入
11.事务的处理
startTransacton();
commitTransaction();
rollbackTransaction();

批处理
如果有很多非查询的（insert/update/delete）语句要处理，为了减少网络通讯的流量，可以进行批处理
sqlMaClientp.startBatch();
sqlMapClient.endBatch();

12.iterate在ibatis里的运用，List参数名后面一定要加“[]”，防止解析器简单的把List解析成String
<select id="getUserInfoByName" resultMap="userResult" parameterClass="java.util.List">
select * from tuserinfo where f_user_code in
    <iterate open="(" close=")" conjunction="," >
<![CDATA[
           #value[]#
        ]]>
   </iterate>
</select>

13.xmlResultName的运用详细输出结果，直接把查存出来的结果映射成XML document
   <select id="getUser" parameterClass="user" resultClass="xml" xmlResultName="person">
    <![CDATA[
        select name,sex from t_user where id = #id#
     ]]>
   </select>

String xml= (String)sqlMapClient.queryForObject("getUser",user );
System.out.println(xml);

<?xml version="1.0" encoding="UTF-8"?>
   <person>
      <name>we are good !</name>
      <sex>2</sex>
   </person>
14.分页功能的实现
1). 用ibatis自带的分页功能，但是自带分页是把所有数据读入内存再分页的，所以必须自己覆写LimitSqlExecutor方法，
2). 直接使用limit实现
15.ibatis的IDE：http://ibatis.apache.org/ibator.html
16.容易出错的地方 :
1) 在parameterMap和resultMap中，字段数据类型是java.sql.Types类定义的常量名称。常用的数据类型包括BLOB，CHAR，CLOB，DATE，LONGVARBINARY， INTEGER，NULL，NUMERIC，TIME，TIMESTAMP和VARCHAR等。
2) 对于数据表中NULLBALE的字段，必须在parameterMap和resultMap中指定字段的数据类型。
3) 对于数据类型是DATE，CLOB或BLOB的字段，最好在parameterMap和resultMap中指定数据类型。
4) 对于二进制类型的数据，可以将LONGVARBINARY映射成byte[]。
5) 对于文本类型较大的数据，可以将CLOB映射成String。
6) Java Bean必须拥有缺省的构造器（即无参数的构造器）。
7) Java Bean最好实现Serializable接口，以备应用的进一步扩展。

17.曾经写了一个ibatis动态查询的例子：
排序代码如下：
<dynamic prepend=" order by">
<isNotNull property="sortName">
   <isNotEqual property="sortName" compareValue="">
    <![CDATA[#sortName# ]]>
   </isNotEqual>
</isNotNull>
<isNotNull property="sortSequence">
   <isNotEqual property="sortSequence" compareValue="">
    <![CDATA[ #sortSequence# ]]>
   </isNotEqual>
</isNotNull>
</dynamic>
竟然无法排序，后来查了下资料，把“#”改成了“$”就可以了。
现总结下经验：#xxx# xxx代表是属性值,map里面的key或者是你的pojo对象里面的属性,ibatis会自动在它的外面加上引号,表现在sql语句是这样的 where xxx = 'xxx' ;而$xxxx$ 则是把xxxx作为字符串拼接到你的sql语句中,比如 order by topicId , 如果你不用$来拼接而用#的话,外面就会被加上引号，比如你的语句这样写 ... order by #xxx# (xxx就是你传进来的字符串topicId),ibatis 就会把他翻译成 order by 'topicId' 这样就报错了，用$的结果就是这样 order by topicId。

18.ibatis通用sql语句可以单独定义如：
<sql id="whereTemplate">
<dynamic prepend="where">
   <isNotNull prepend="and" property="id">
    <![CDATA[ id = #id# ]]>
   </isNotNull>
</dynamic>
</sql>

<select id="coreGetCountAll" resultClass="java.lang.Integer" parameterClass="coreNote">
<![CDATA[ SELECT COUNT( 1 ) FROM note ]]>
<include refid="whereNoteTemplate" />
</select>

本文链接

面向程序员的数据库访问性能优化法则 http://blog.csdn.net/yzsind/archive/2010/12/06/6059209.aspx

2010-12-14T08:50:00Z

面向程序员的数据库访问性能优化法则

http://blog.csdn.net/yzsind/archive/2010/12/06/6059209.aspx

特别说明：

1、本文只是面对数据库应用开发的程序员，不适合专业DBA，DBA在数据库性能优化方面需要了解更多的知识；

2、本文许多示例及概念是基于Oracle数据库描述，对于其它关系型数据库也可以参考，但许多观点不适合于KV数据库或内存数据库或者是基于SSD技术的数据库；

3、本文未深入数据库优化中最核心的执行计划分析技术。

读者对像：

开发人员：如果你是做数据库开发，那本文的内容非常适合，因为本文是从程序员的角度来谈数据库性能优化。

架构师：如果你已经是数据库应用的架构师，那本文的知识你应该清楚90%，否则你可能是一个喜欢折腾的架构师。

DBA（数据库管理员）：大型数据库优化的知识非常复杂，本文只是从程序员的角度来谈性能优化，DBA除了需要了解这些知识外，还需要深入数据库的内部体系架构来解决问题。

引言

在网上有很多文章介绍数据库优化知识，但是大部份文章只是对某个一个方面进行说明，而对于我们程序员来说这种介绍并不能很好的掌握优化知识，因为很多介绍只是对一些特定的场景优化的，所以反而有时会产生误导或让程序员感觉不明白其中的奥妙而对数据库优化感觉很神秘。

很多程序员总是问如何学习数据库优化，有没有好的教材之类的问题。在书店也看到了许多数据库优化的专业书籍，但是感觉更多是面向DBA或者是PL/SQL开发方面的知识，个人感觉不太适合普通程序员。而要想做到数据库优化的高手，不是花几周，几个月就能达到的，这并不是因为数据库优化有多高深，而是因为要做好优化一方面需要有非常好的技术功底，对操作系统、存储硬件网络、数据库原理等方面有比较扎实的基础知识，另一方面是需要花大量时间对特定的数据库进行实践测试与总结。

作为一个程序员，我们也许不清楚线上正式的服务器硬件配置，我们不可能像DBA那样专业的对数据库进行各种实践测试与总结，但我们都应该非常了解我们SQL的业务逻辑，我们清楚SQL中访问表及字段的数据情况，我们其实只关心我们的SQL是否能尽快返回结果。那程序员如何利用已知的知识进行数据库优化？如何能快速定位SQL性能问题并找到正确的优化方向？

面对这些问题，笔者总结了一些面向程序员的基本优化法则，本文将结合实例来坦述数据库开发的优化知识。

一、数据库访问优化法则简介
要正确的优化SQL，我们需要快速定位能性的瓶颈点，也就是说快速找到我们SQL主要的开销在哪里？而大多数情况性能最慢的设备会是瓶颈点，如下载时网络速度可能会是瓶颈点，本地复制文件时硬盘可能会是瓶颈点，为什么这些一般的工作我们能快速确认瓶颈点呢，因为我们对这些慢速设备的性能数据有一些基本的认识，如网络带宽是2Mbps，硬盘是每分钟7200转等等。因此，为了快速找到SQL的性能瓶颈点，我们也需要了解我们计算机系统的硬件基本性能指标，下图展示的当前主流计算机性能指标数据。

从图上可以看到基本上每种设备都有两个指标：

延时（响应时间）：表示硬件的突发处理能力；

带宽（吞吐量）：代表硬件持续处理能力。

从上图可以看出，计算机系统硬件性能从高到代依次为：

CPU——Cache(L1-L2-L3)——内存——SSD硬盘——网络——硬盘

由于SSD硬盘还处于快速发展阶段，所以本文的内容不涉及SSD相关应用系统。

根据数据库知识，我们可以列出每种硬件主要的工作内容：

CPU及内存：缓存数据访问、比较、排序、事务检测、SQL解析、函数或逻辑运算；

网络：结果数据传输、SQL请求、远程数据库访问（dblink）；

硬盘：数据访问、数据写入、日志记录、大数据量排序、大表连接。

根据当前计算机硬件的基本性能指标及其在数据库中主要操作内容，可以整理出如下图所示的性能基本优化法则：

这个优化法则归纳为5个层次：

1、减少数据访问（减少磁盘访问）

2、返回更少数据（减少网络传输或磁盘访问）

3、减少交互次数（减少网络传输）

4、减少服务器CPU开销（减少CPU及内存开销）

5、利用更多资源（增加资源）

由于每一层优化法则都是解决其对应硬件的性能问题，所以带来的性能提升比例也不一样。传统数据库系统设计是也是尽可能对低速设备提供优化方法，因此针对低速设备问题的可优化手段也更多，优化成本也更低。我们任何一个SQL的性能优化都应该按这个规则由上到下来诊断问题并提出解决方案，而不应该首先想到的是增加资源解决问题。

以下是每个优化法则层级对应优化效果及成本经验参考：

优化法则
性能提升效果
优化成本

减少数据访问
1~1000
低

返回更少数据
1~100
低

减少交互次数
1~20
低

减少服务器CPU开销
1~5
低

利用更多资源
@~10
高

接下来，我们针对5种优化法则列举常用的优化手段并结合实例分析。

二、Oracle数据库两个基本概念
数据块(Block)
数据块是数据库中数据在磁盘中存储的最小单位，也是一次IO访问的最小单位，一个数据块通常可以存储多条记录，数据块大小是DBA在创建数据库或表空间时指定，可指定为2K、4K、8K、16K或32K字节。下图是一个Oracle数据库典型的物理结构，一个数据库可以包括多个数据文件，一个数据文件内又包含多个数据块；

ROWID
ROWID是每条记录在数据库中的唯一标识，通过ROWID可以直接定位记录到对应的文件号及数据块位置。ROWID内容包括文件号、对像号、数据块号、记录槽号，如下图所示：

三、数据库访问优化法则详解
1、减少数据访问
1.1、创建并使用正确的索引
数据库索引的原理非常简单，但在复杂的表中真正能正确使用索引的人很少，即使是专业的DBA也不一定能完全做到最优。

索引会大大增加表记录的DML(INSERT,UPDATE,DELETE)开销，正确的索引可以让性能提升100，1000倍以上，不合理的索引也可能会让性能下降100倍，因此在一个表中创建什么样的索引需要平衡各种业务需求。

索引常见问题：

索引有哪些种类？

常见的索引有B-TREE索引、位图索引、全文索引，位图索引一般用于数据仓库应用，全文索引由于使用较少，这里不深入介绍。B-TREE索引包括很多扩展类型，如组合索引、反向索引、函数索引等等，以下是B-TREE索引的简单介绍：

B-TREE索引也称为平衡树索引(Balance Tree)，它是一种按字段排好序的树形目录结构，主要用于提升查询性能和唯一约束支持。B-TREE索引的内容包括根节点、分支节点、叶子节点。

叶子节点内容：索引字段内容+表记录ROWID

根节点，分支节点内容：当一个数据块中不能放下所有索引字段数据时，就会形成树形的根节点或分支节点，根节点与分支节点保存了索引树的顺序及各层级间的引用关系。

一个普通的BTREE索引结构示意图如下所示：

如果我们把一个表的内容认为是一本字典，那索引就相当于字典的目录，如下图所示：

图中是一个字典按部首+笔划数的目录，相当于给字典建了一个按部首+笔划的组合索引。

一个表中可以建多个索引，就如一本字典可以建多个目录一样（按拼音、笔划、部首等等）。

一个索引也可以由多个字段组成，称为组合索引，如上图就是一个按部首+笔划的组合目录。

SQL什么条件会使用索引？

当字段上建有索引时，通常以下情况会使用索引：

INDEX_COLUMN = ?

INDEX_COLUMN > ?

INDEX_COLUMN >= ?

INDEX_COLUMN < ?

INDEX_COLUMN <= ?

INDEX_COLUMN between ? and ?

INDEX_COLUMN in (?,?,...,?)

INDEX_COLUMN like ?||'%'（后导模糊查询）

T1. INDEX_COLUMN=T2. COLUMN1（两个表通过索引字段关联）

SQL什么条件不会使用索引？

查询条件
不能使用索引原因

INDEX_COLUMN <> ?

INDEX_COLUMN not in (?,?,...,?)
不等于操作不能使用索引

function(INDEX_COLUMN) = ?

INDEX_COLUMN + 1 = ?

INDEX_COLUMN || 'a' = ?
经过普通运算或函数运算后的索引字段不能使用索引

INDEX_COLUMN like '%'||?

INDEX_COLUMN like '%'||?||'%'
含前导模糊查询的Like语法不能使用索引

INDEX_COLUMN is null
B-TREE索引里不保存字段为NULL值记录，因此IS NULL不能使用索引

NUMBER_INDEX_COLUMN='12345'

CHAR_INDEX_COLUMN=12345
Oracle在做数值比较时需要将两边的数据转换成同一种数据类型，如果两边数据类型不同时会对字段值隐式转换，相当于加了一层函数处理，所以不能使用索引。

a.INDEX_COLUMN=a.COLUMN_1
给索引查询的值应是已知数据，不能是未知字段值。

注：

经过函数运算字段的字段要使用可以使用函数索引，这种需求建议与DBA沟通。

有时候我们会使用多个字段的组合索引，如果查询条件中第一个字段不能使用索引，那整个查询也不能使用索引

如：我们company表建了一个id+name的组合索引，以下SQL是不能使用索引的

Select * from company where name=?

Oracle9i后引入了一种index skip scan的索引方式来解决类似的问题，但是通过index skip scan提高性能的条件比较特殊，使用不好反而性能会更差。

我们一般在什么字段上建索引？

这是一个非常复杂的话题，需要对业务及数据充分分析后再能得出结果。主键及外键通常都要有索引，其它需要建索引的字段应满足以下条件：

1、字段出现在查询条件中，并且查询条件可以使用索引；

2、语句执行频率高，一天会有几千次以上；

3、通过字段条件可筛选的记录集很小，那数据筛选比例是多少才适合？

这个没有固定值，需要根据表数据量来评估，以下是经验公式，可用于快速评估：

小表(记录数小于10000行的表)：筛选比例<10%；

大表：(筛选返回记录数)<(表总记录数*单条记录长度)/10000/16

单条记录长度≈字段平均内容长度之和+字段数*2

以下是一些字段是否需要建B-TREE索引的经验分类：

字段类型
常见字段名

需要建索引的字段
主键
ID,PK

外键
PRODUCT_ID,COMPANY_ID,MEMBER_ID,ORDER_ID,TRADE_ID,PAY_ID

有对像或身份标识意义字段
HASH_CODE,USERNAME,IDCARD_NO,EMAIL,TEL_NO,IM_NO

索引慎用字段,需要进行数据分布及使用场景详细评估
日期
GMT_CREATE,GMT_MODIFIED

年月
YEAR,MONTH

状态标志
PRODUCT_STATUS,ORDER_STATUS,IS_DELETE,VIP_FLAG

类型
ORDER_TYPE,IMAGE_TYPE,GENDER,CURRENCY_TYPE

区域
COUNTRY,PROVINCE,CITY

操作人员
CREATOR,AUDITOR

数值
LEVEL,AMOUNT,SCORE

长字符
ADDRESS,COMPANY_NAME,SUMMARY,SUBJECT

不适合建索引的字段
描述备注
DESCRIPTION,REMARK,MEMO,DETAIL

大字段
FILE_CONTENT,EMAIL_CONTENT

如何知道SQL是否使用了正确的索引？

简单SQL可以根据索引使用语法规则判断，复杂的SQL不好办，判断SQL的响应时间是一种策略，但是这会受到数据量、主机负载及缓存等因素的影响，有时数据全在缓存里，可能全表访问的时间比索引访问时间还少。要准确知道索引是否正确使用，需要到数据库中查看SQL真实的执行计划，这个话题比较复杂，详见SQL执行计划专题介绍。

索引对DML(INSERT,UPDATE,DELETE)附加的开销有多少？

这个没有固定的比例，与每个表记录的大小及索引字段大小密切相关，以下是一个普通表测试数据，仅供参考：

索引对于Insert性能降低56%

索引对于Update性能降低47%

索引对于Delete性能降低29%

因此对于写IO压力比较大的系统，表的索引需要仔细评估必要性，另外索引也会占用一定的存储空间。

1.2、只通过索引访问数据
有些时候，我们只是访问表中的几个字段，并且字段内容较少，我们可以为这几个字段单独建立一个组合索引，这样就可以直接只通过访问索引就能得到数据，一般索引占用的磁盘空间比表小很多，所以这种方式可以大大减少磁盘IO开销。

如：select id,name from company where type='2';

如果这个SQL经常使用，我们可以在type,id,name上创建组合索引

create index my_comb_index on company(type,id,name);

有了这个组合索引后，SQL就可以直接通过my_comb_index索引返回数据，不需要访问company表。

还是拿字典举例：有一个需求，需要查询一本汉语字典中所有汉字的个数，如果我们的字典没有目录索引，那我们只能从字典内容里一个一个字计数，最后返回结果。如果我们有一个拼音目录，那就可以只访问拼音目录的汉字进行计数。如果一本字典有1000页，拼音目录有20页，那我们的数据访问成本相当于全表访问的50分之一。

切记，性能优化是无止境的，当性能可以满足需求时即可，不要过度优化。在实际数据库中我们不可能把每个SQL请求的字段都建在索引里，所以这种只通过索引访问数据的方法一般只用于核心应用，也就是那种对核心表访问量最高且查询字段数据量很少的查询。

1.3、优化SQL执行计划
SQL执行计划是关系型数据库最核心的技术之一，它表示SQL执行时的数据访问算法。由于业务需求越来越复杂，表数据量也越来越大，程序员越来越懒惰，SQL也需要支持非常复杂的业务逻辑，但SQL的性能还需要提高，因此，优秀的关系型数据库除了需要支持复杂的SQL语法及更多函数外，还需要有一套优秀的算法库来提高SQL性能。

目前ORACLE有SQL执行计划的算法约300种，而且一直在增加，所以SQL执行计划是一个非常复杂的课题，一个普通DBA能掌握50种就很不错了，就算是资深DBA也不可能把每个执行计划的算法描述清楚。虽然有这么多种算法，但并不表示我们无法优化执行计划，因为我们常用的SQL执行计划算法也就十几个，如果一个程序员能把这十几个算法搞清楚，那就掌握了80%的SQL执行计划调优知识。

由于篇幅的原因，SQL执行计划需要专题介绍，在这里就不多说了。

2、返回更少的数据
2.1、数据分页处理
一般数据分页方式有：

2.1.1、客户端(应用程序或浏览器)分页
将数据从应用服务器全部下载到本地应用程序或浏览器，在应用程序或浏览器内部通过本地代码进行分页处理

优点：编码简单，减少客户端与应用服务器网络交互次数

缺点：首次交互时间长，占用客户端内存

适应场景：客户端与应用服务器网络延时较大，但要求后续操作流畅，如手机GPRS，超远程访问（跨国）等等。

2.1.2、应用服务器分页
将数据从数据库服务器全部下载到应用服务器，在应用服务器内部再进行数据筛选。以下是一个应用服务器端Java程序分页的示例：

List list=executeQuery(“select * from employee order by id”);

Int count= list.size();

List subList= list.subList(10, 20);

优点：编码简单，只需要一次SQL交互，总数据与分页数据差不多时性能较好。

缺点：总数据量较多时性能较差。

适应场景：数据库系统不支持分页处理，数据量较小并且可控。

2.1.3、数据库SQL分页
采用数据库SQL分页需要两次SQL完成

一个SQL计算总数量

一个SQL返回分页后的数据

优点：性能好

缺点：编码复杂，各种数据库语法不同，需要两次SQL交互。

oracle数据库一般采用rownum来进行分页，常用分页语法有如下两种：

直接通过rownum分页：

select * from (

select a.*,rownum rn from

(select * from product a where company_id=? order by status) a

where rownum<=20)

where rn>10;

数据访问开销=索引IO+索引全部记录结果对应的表数据IO

采用rowid分页语法

优化原理是通过纯索引找出分页记录的ROWID，再通过ROWID回表返回数据，要求内层查询和排序字段全在索引里。

create index myindex on product(company_id,status);

select b.* from (

select * from (

select a.*,rownum rn from

(select rowid rid,status from product a where company_id=? order by status) a

where rownum<=20)

where rn>10) a, product b

where a.rid=b.rowid;

数据访问开销=索引IO+索引分页结果对应的表数据IO

实例：

一个公司产品有1000条记录，要分页取其中20个产品，假设访问公司索引需要50个IO，2条记录需要1个表数据IO。

那么按第一种ROWNUM分页写法，需要550(50+1000/2)个IO，按第二种ROWID分页写法，只需要60个IO(50+20/2);

2.2、只返回需要的字段
通过去除不必要的返回字段可以提高性能，例：

调整前：select * from product where company_id=?;

调整后：select id,name from product where company_id=?;

优点：

1、减少数据在网络上传输开销

2、减少服务器数据处理开销

3、减少客户端内存占用

4、字段变更时提前发现问题，减少程序BUG

5、如果访问的所有字段刚好在一个索引里面，则可以使用纯索引访问提高性能。

缺点：增加编码工作量

由于会增加一些编码工作量，所以一般需求通过开发规范来要求程序员这么做，否则等项目上线后再整改工作量更大。

如果你的查询表中有大字段或内容较多的字段，如备注信息、文件内容等等，那在查询表时一定要注意这方面的问题，否则可能会带来严重的性能问题。如果表经常要查询并且请求大内容字段的概率很低，我们可以采用分表处理，将一个大表分拆成两个一对一的关系表，将不常用的大内容字段放在一张单独的表中。如一张存储上传文件的表：

T_FILE（ID,FILE_NAME,FILE_SIZE,FILE_TYPE,FILE_CONTENT）

我们可以分拆成两张一对一的关系表：

T_FILE（ID,FILE_NAME,FILE_SIZE,FILE_TYPE）

T_FILECONTENT（ID, FILE_CONTENT）

通过这种分拆，可以大大提少T_FILE表的单条记录及总大小，这样在查询T_FILE时性能会更好，当需要查询FILE_CONTENT字段内容时再访问T_FILECONTENT表。

3、减少交互次数
3.1、batch DML
数据库访问框架一般都提供了批量提交的接口，jdbc支持batch的提交处理方法，当你一次性要往一个表中插入1000万条数据时，如果采用普通的executeUpdate处理，那么和服务器交互次数为1000万次，按每秒钟可以向数据库服务器提交10000次估算，要完成所有工作需要1000秒。如果采用批量提交模式，1000条提交一次，那么和服务器交互次数为1万次，交互次数大大减少。采用batch操作一般不会减少很多数据库服务器的物理IO，但是会大大减少客户端与服务端的交互次数，从而减少了多次发起的网络延时开销，同时也会降低数据库的CPU开销。

假设要向一个普通表插入1000万数据，每条记录大小为1K字节，表上没有任何索引，客户端与数据库服务器网络是100Mbps，以下是根据现在一般计算机能力估算的各种batch大小性能对比值：

单位：ms
No batch
Batch=10
Batch=100
Batch=1000
Batch=10000

服务器事务处理时间
0.1
0.1
0.1
0.1
0.1

服务器IO处理时间
0.02
0.2
2
20
200

网络交互发起时间
0.1
0.1
0.1
0.1
0.1

网络数据传输时间
0.01
0.1
1
10
100

小计
0.23
0.5
3.2
30.2
300.2

平均每条记录处理时间
0.23
0.05
0.032
0.0302
0.03002

从上可以看出，Insert操作加大Batch可以对性能提高近8倍性能，一般根据主键的Update或Delete操作也可能提高2-3倍性能，但不如Insert明显，因为Update及Delete操作可能有比较大的开销在物理IO访问。以上仅是理论计算值，实际情况需要根据具体环境测量。

3.2、In List
很多时候我们需要按一些ID查询数据库记录，我们可以采用一个ID一个请求发给数据库，如下所示：

for :var in ids[] do begin

select * from mytable where id=:var;

end;

我们也可以做一个小的优化，如下所示，用ID INLIST的这种方式写SQL：

select * from mytable where id in(:id1,id2,...,idn);

通过这样处理可以大大减少SQL请求的数量，从而提高性能。那如果有10000个ID，那是不是全部放在一条SQL里处理呢？答案肯定是否定的。首先大部份数据库都会有SQL长度和IN里个数的限制，如ORACLE的IN里就不允许超过1000个值。

另外当前数据库一般都是采用基于成本的优化规则，当IN数量达到一定值时有可能改变SQL执行计划，从索引访问变成全表访问，这将使性能急剧变化。随着SQL中IN的里面的值个数增加，SQL的执行计划会更复杂，占用的内存将会变大，这将会增加服务器CPU及内存成本。

评估在IN里面一次放多少个值还需要考虑应用服务器本地内存的开销，有并发访问时要计算本地数据使用周期内的并发上限，否则可能会导致内存溢出。

综合考虑，一般IN里面的值个数超过20个以后性能基本没什么太大变化，也特别说明不要超过100，超过后可能会引起执行计划的不稳定性及增加数据库CPU及内存成本，这个需要专业DBA评估。

3.3、设置Fetch Size
当我们采用select从数据库查询数据时，数据默认并不是一条一条返回给客户端的，也不是一次全部返回客户端的，而是根据客户端fetch_size参数处理，每次只返回fetch_size条记录，当客户端游标遍历到尾部时再从服务端取数据，直到最后全部传送完成。所以如果我们要从服务端一次取大量数据时，可以加大fetch_size，这样可以减少结果数据传输的交互次数及服务器数据准备时间，提高性能。

以下是jdbc测试的代码，采用本地数据库，表缓存在数据库CACHE中，因此没有网络连接及磁盘IO开销，客户端只遍历游标，不做任何处理，这样更能体现fetch参数的影响：

String vsql ="select * from t_employee";

PreparedStatement pstmt = conn.prepareStatement(vsql,ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);

pstmt.setFetchSize(1000);

ResultSet rs = pstmt.executeQuery(vsql);

int cnt = rs.getMetaData().getColumnCount();

Object o;

while (rs.next()) {

for (int i = 1; i <= cnt; i++) {

o = rs.getObject(i);

}

测试示例中的employee表有100000条记录，每条记录平均长度135字节

以下是测试结果，对每种fetchsize测试5次再取平均值：

fetchsize
elapse_time（s）

1
20.516

2
11.34

4
6.894

8
4.65

16
3.584

32
2.865

64
2.656

128
2.44

256
2.765

512
3.075

1024
2.862

2048
2.722

4096
2.681

8192
2.715

Oracle jdbc fetchsize默认值为10，由上测试可以看出fetchsize对性能影响还是比较大的，但是当fetchsize大于100时就基本上没有影响了。fetchsize并不会存在一个最优的固定值，因为整体性能与记录集大小及硬件平台有关。根据测试结果建议当一次性要取大量数据时这个值设置为100左右，不要小于40。注意，fetchsize不能设置太大，如果一次取出的数据大于JVM的内存会导致内存溢出，所以建议不要超过1000，太大了也没什么性能提高，反而可能会增加内存溢出的危险。

注：图中fetchsize在128以后会有一些小的波动，这并不是测试误差，而是由于resultset填充到具体对像时间不同的原因，由于resultset已经到本地内存里了，所以估计是由于CPU的L1,L2 Cache命中率变化造成，由于变化不大，所以笔者也未深入分析原因。

iBatis的SqlMapping配置文件可以对每个SQL语句指定fetchsize大小，如下所示：

select * from employee

</select>

3.4、使用存储过程
大型数据库一般都支持存储过程，合理的利用存储过程也可以提高系统性能。如你有一个业务需要将A表的数据做一些加工然后更新到B表中，但是又不可能一条SQL完成，这时你需要如下3步操作：

a：将A表数据全部取出到客户端；

b：计算出要更新的数据；

c：将计算结果更新到B表。

如果采用存储过程你可以将整个业务逻辑封装在存储过程里，然后在客户端直接调用存储过程处理，这样可以减少网络交互的成本。

当然，存储过程也并不是十全十美，存储过程有以下缺点：

a、不可移植性，每种数据库的内部编程语法都不太相同，当你的系统需要兼容多种数据库时最好不要用存储过程。

b、学习成本高，DBA一般都擅长写存储过程，但并不是每个程序员都能写好存储过程，除非你的团队有较多的开发人员熟悉写存储过程，否则后期系统维护会产生问题。

c、业务逻辑多处存在，采用存储过程后也就意味着你的系统有一些业务逻辑不是在应用程序里处理，这种架构会增加一些系统维护和调试成本。

d、存储过程和常用应用程序语言不一样，它支持的函数及语法有可能不能满足需求，有些逻辑就只能通过应用程序处理。

e、如果存储过程中有复杂运算的话，会增加一些数据库服务端的处理成本，对于集中式数据库可能会导致系统可扩展性问题。

f、为了提高性能，数据库会把存储过程代码编译成中间运行代码(类似于java的class文件)，所以更像静态语言。当存储过程引用的对像(表、视图等等)结构改变后，存储过程需要重新编译才能生效，在24*7高并发应用场景，一般都是在线变更结构的，所以在变更的瞬间要同时编译存储过程，这可能会导致数据库瞬间压力上升引起故障(Oracle数据库就存在这样的问题)。

个人观点：普通业务逻辑尽量不要使用存储过程，定时性的ETL任务或报表统计函数可以根据团队资源情况采用存储过程处理。

3.5、优化业务逻辑
要通过优化业务逻辑来提高性能是比较困难的，这需要程序员对所访问的数据及业务流程非常清楚。

举一个案例：

某移动公司推出优惠套参，活动对像为VIP会员并且2010年1，2，3月平均话费20元以上的客户。

那我们的检测逻辑为：

select avg(money) as avg_money from bill where phone_no='13988888888' and date between '201001' and '201003';

select vip_flag from member where phone_no='13988888888';

if avg_money>20 and vip_flag=true then

begin

执行套参();

end;

如果我们修改业务逻辑为:

select avg(money) as avg_money from bill where phone_no='13988888888' and date between '201001' and '201003';

if avg_money>20 then

begin

select vip_flag from member where phone_no='13988888888';

if vip_flag=true then

begin

执行套参();

end;

通过这样可以减少一些判断vip_flag的开销，平均话费20元以下的用户就不需要再检测是否VIP了。

如果程序员分析业务，VIP会员比例为1%，平均话费20元以上的用户比例为90%，那我们改成如下：

select vip_flag from member where phone_no='13988888888';

if vip_flag=true then

begin

select avg(money) as avg_money from bill where phone_no='13988888888' and date between '201001' and '201003';

if avg_money>20 then

begin

执行套参();

end;

这样就只有1%的VIP会员才会做检测平均话费，最终大大减少了SQL的交互次数。

以上只是一个简单的示例，实际的业务总是比这复杂得多，所以一般只是高级程序员更容易做出优化的逻辑，但是我们需要有这样一种成本优化的意识。

3.6、使用ResultSet游标处理记录
现在大部分Java框架都是通过jdbc从数据库取出数据，然后装载到一个list里再处理，list里可能是业务Object，也可能是hashmap。

由于JVM内存一般都小于4G，所以不可能一次通过sql把大量数据装载到list里。为了完成功能，很多程序员喜欢采用分页的方法处理，如一次从数据库取1000条记录，通过多次循环搞定，保证不会引起JVM Out of memory问题。

以下是实现此功能的代码示例，t_employee表有10万条记录，设置分页大小为1000：

d1 = Calendar.getInstance().getTime();

vsql = "select count(*) cnt from t_employee";

pstmt = conn.prepareStatement(vsql);

ResultSet rs = pstmt.executeQuery();

Integer cnt = 0;

while (rs.next()) {

cnt = rs.getInt("cnt");

}

Integer lastid=0;

Integer pagesize=1000;

System.out.println("cnt:" + cnt);

String vsql = "select count(*) cnt from t_employee";

PreparedStatement pstmt = conn.prepareStatement(vsql);

ResultSet rs = pstmt.executeQuery();

Integer cnt = 0;

while (rs.next()) {

cnt = rs.getInt("cnt");

}

Integer lastid = 0;

Integer pagesize = 1000;

System.out.println("cnt:" + cnt);

for (int i = 0; i <= cnt / pagesize; i++) {

vsql = "select * from (select * from t_employee where id>? order by id) where rownum<=?";

pstmt = conn.prepareStatement(vsql);

pstmt.setFetchSize(1000);

pstmt.setInt(1, lastid);

pstmt.setInt(2, pagesize);

rs = pstmt.executeQuery();

int col_cnt = rs.getMetaData().getColumnCount();

Object o;

while (rs.next()) {

for (int j = 1; j <= col_cnt; j++) {

o = rs.getObject(j);

}

lastid = rs.getInt("id");

}

rs.close();

pstmt.close();

}

以上代码实际执行时间为6.516秒

很多持久层框架为了尽量让程序员使用方便，封装了jdbc通过statement执行数据返回到resultset的细节，导致程序员会想采用分页的方式处理问题。实际上如果我们采用jdbc原始的resultset游标处理记录，在resultset循环读取的过程中处理记录，这样就可以一次从数据库取出所有记录。显著提高性能。

这里需要注意的是，采用resultset游标处理记录时，应该将游标的打开方式设置为FORWARD_READONLY模式(ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY)，否则会把结果缓存在JVM里，造成JVM Out of memory问题。

代码示例：

String vsql ="select * from t_employee";

PreparedStatement pstmt = conn.prepareStatement(vsql,ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);

pstmt.setFetchSize(100);

ResultSet rs = pstmt.executeQuery(vsql);

int col_cnt = rs.getMetaData().getColumnCount();

Object o;

while (rs.next()) {

for (int j = 1; j <= col_cnt; j++) {

o = rs.getObject(j);

}

调整后的代码实际执行时间为3.156秒

从测试结果可以看出性能提高了1倍多，如果采用分页模式数据库每次还需发生磁盘IO的话那性能可以提高更多。

iBatis等持久层框架考虑到会有这种需求，所以也有相应的解决方案，在iBatis里我们不能采用queryForList的方法，而应用该采用queryWithRowHandler加回调事件的方式处理，如下所示：

MyRowHandler myrh=new MyRowHandler();

sqlmap.queryWithRowHandler("getAllEmployee", myrh);

class MyRowHandler implements RowHandler {

public void handleRow(Object o) {

//todo something

}

iBatis的queryWithRowHandler很好的封装了resultset遍历的事件处理，效果及性能与resultset遍历一样，也不会产生JVM内存溢出。

4、减少数据库服务器CPU运算
4.1、使用绑定变量
绑定变量是指SQL中对变化的值采用变量参数的形式提交，而不是在SQL中直接拼写对应的值。

非绑定变量写法：Select * from employee where id=1234567

绑定变量写法：

Select * from employee where id=?

Preparestatement.setInt(1,1234567)

Java中Preparestatement就是为处理绑定变量提供的对像，绑定变量有以下优点：

1、防止SQL注入

2、提高SQL可读性

3、提高SQL解析性能，不使用绑定变更我们一般称为硬解析，使用绑定变量我们称为软解析。

第1和第2点很好理解，做编码的人应该都清楚，这里不详细说明。关于第3点，到底能提高多少性能呢，下面举一个例子说明：

假设有这个这样的一个数据库主机：

2个4核CPU

100块磁盘，每个磁盘支持IOPS为160

业务应用的SQL如下：

select * from table where pk=?

这个SQL平均4个IO（3个索引IO+1个数据IO）

IO缓存命中率75%（索引全在内存中，数据需要访问磁盘）

SQL硬解析CPU消耗：1ms （常用经验值）

SQL软解析CPU消耗：0.02ms（常用经验值）

假设CPU每核性能是线性增长，访问内存Cache中的IO时间忽略，要求计算系统对如上应用采用硬解析与采用软解析支持的每秒最大并发数：

是否使用绑定变量
CPU支持最大并发数
磁盘IO支持最大并发数

不使用
2*4*1000=8000
100*160=16000

使用
2*4*1000/0.02=400000
100*160=16000

从以上计算可以看出，不使用绑定变量的系统当并发达到8000时会在CPU上产生瓶颈，当使用绑定变量的系统当并行达到16000时会在磁盘IO上产生瓶颈。所以如果你的系统CPU有瓶颈时请先检查是否存在大量的硬解析操作。

使用绑定变量为何会提高SQL解析性能，这个需要从数据库SQL执行原理说明，一条SQL在Oracle数据库中的执行过程如下图所示：

当一条SQL发送给数据库服务器后，系统首先会将SQL字符串进行hash运算，得到hash值后再从服务器内存里的SQL缓存区中进行检索，如果有相同的SQL字符，并且确认是同一逻辑的SQL语句，则从共享池缓存中取出SQL对应的执行计划，根据执行计划读取数据并返回结果给客户端。

如果在共享池中未发现相同的SQL则根据SQL逻辑生成一条新的执行计划并保存在SQL缓存区中，然后根据执行计划读取数据并返回结果给客户端。

为了更快的检索SQL是否在缓存区中，首先进行的是SQL字符串hash值对比，如果未找到则认为没有缓存，如果存在再进行下一步的准确对比，所以要命中SQL缓存区应保证SQL字符是完全一致，中间有大小写或空格都会认为是不同的SQL。

如果我们不采用绑定变量，采用字符串拼接的模式生成SQL,那么每条SQL都会产生执行计划，这样会导致共享池耗尽，缓存命中率也很低。

一些不使用绑定变量的场景：

a、数据仓库应用，这种应用一般并发不高，但是每个SQL执行时间很长，SQL解析的时间相比SQL执行时间比较小，绑定变量对性能提高不明显。数据仓库一般都是内部分析应用，所以也不太会发生SQL注入的安全问题。

b、数据分布不均匀的特殊逻辑，如产品表，记录有1亿，有一产品状态字段，上面建有索引，有审核中，审核通过，审核未通过3种状态，其中审核通过9500万，审核中1万，审核不通过499万。

要做这样一个查询：

select count(*) from product where status=?

采用绑定变量的话，那么只会有一个执行计划，如果走索引访问，那么对于审核中查询很快，对审核通过和审核不通过会很慢；如果不走索引，那么对于审核中与审核通过和审核不通过时间基本一样；

对于这种情况应该不使用绑定变量，而直接采用字符拼接的方式生成SQL，这样可以为每个SQL生成不同的执行计划，如下所示。

select count(*) from product where status='approved'; //不使用索引

select count(*) from product where status='tbd'; //不使用索引

select count(*) from product where status='auditing';//使用索引

4.2、合理使用排序
Oracle的排序算法一直在优化，但是总体时间复杂度约等于nLog(n)。普通OLTP系统排序操作一般都是在内存里进行的，对于数据库来说是一种CPU的消耗，曾在PC机做过测试，单核普通CPU在1秒钟可以完成100万条记录的全内存排序操作，所以说由于现在CPU的性能增强，对于普通的几十条或上百条记录排序对系统的影响也不会很大。但是当你的记录集增加到上万条以上时，你需要注意是否一定要这么做了，大记录集排序不仅增加了CPU开销，而且可能会由于内存不足发生硬盘排序的现象，当发生硬盘排序时性能会急剧下降，这种需求需要与DBA沟通再决定，取决于你的需求和数据，所以只有你自己最清楚，而不要被别人说排序很慢就吓倒。

以下列出了可能会发生排序操作的SQL语法：

Order by

Group by

Distinct

Exists子查询

Not Exists子查询

In子查询

Not In子查询

Union（并集），Union All也是一种并集操作，但是不会发生排序，如果你确认两个数据集不需要执行去除重复数据操作，那请使用Union All 代替Union。

Minus（差集）

Intersect（交集）

Create Index

Merge Join，这是一种两个表连接的内部算法，执行时会把两个表先排序好再连接，应用于两个大表连接的操作。如果你的两个表连接的条件都是等值运算，那可以采用Hash Join来提高性能，因为Hash Join使用Hash 运算来代替排序的操作。具体原理及设置参考SQL执行计划优化专题。

4.3、减少比较操作
我们SQL的业务逻辑经常会包含一些比较操作，如a=b，a<b之类的操作，对于这些比较操作数据库都体现得很好，但是如果有以下操作，我们需要保持警惕：

Like模糊查询，如下所示：

a like ‘%abc%’

Like模糊查询对于数据库来说不是很擅长，特别是你需要模糊检查的记录有上万条以上时，性能比较糟糕，这种情况一般可以采用专用Search或者采用全文索引方案来提高性能。

不能使用索引定位的大量In List，如下所示：

a in (:1,:2,:3,…,:n) ----n>20

如果这里的a字段不能通过索引比较，那数据库会将字段与in里面的每个值都进行比较运算，如果记录数有上万以上，会明显感觉到SQL的CPU开销加大，这个情况有两种解决方式：

a、将in列表里面的数据放入一张中间小表，采用两个表Hash Join关联的方式处理；

b、采用str2varList方法将字段串列表转换一个临时表处理，关于str2varList方法可以在网上直接查询，这里不详细介绍。

以上两种解决方案都需要与中间表Hash Join的方式才能提高性能，如果采用了Nested Loop的连接方式性能会更差。

如果发现我们的系统IO没问题但是CPU负载很高，就有可能是上面的原因，这种情况不太常见，如果遇到了最好能和DBA沟通并确认准确的原因。

4.4、大量复杂运算在客户端处理
什么是复杂运算，一般我认为是一秒钟CPU只能做10万次以内的运算。如含小数的对数及指数运算、三角函数、3DES及BASE64数据加密算法等等。

如果有大量这类函数运算，尽量放在客户端处理，一般CPU每秒中也只能处理1万-10万次这样的函数运算，放在数据库内不利于高并发处理。

5、利用更多的资源
5.1、客户端多进程并行访问
多进程并行访问是指在客户端创建多个进程(线程)，每个进程建立一个与数据库的连接，然后同时向数据库提交访问请求。当数据库主机资源有空闲时，我们可以采用客户端多进程并行访问的方法来提高性能。如果数据库主机已经很忙时，采用多进程并行访问性能不会提高，反而可能会更慢。所以使用这种方式最好与DBA或系统管理员进行沟通后再决定是否采用。

例如：

我们有10000个产品ID，现在需要根据ID取出产品的详细信息，如果单线程访问，按每个IO要5ms计算，忽略主机CPU运算及网络传输时间，我们需要50s才能完成任务。如果采用5个并行访问，每个进程访问2000个ID，那么10s就有可能完成任务。

那是不是并行数越多越好呢，开1000个并行是否只要50ms就搞定，答案肯定是否定的，当并行数超过服务器主机资源的上限时性能就不会再提高，如果再增加反而会增加主机的进程间调度成本和进程冲突机率。

以下是一些如何设置并行数的基本建议：

如果瓶颈在服务器主机，但是主机还有空闲资源，那么最大并行数取主机CPU核数和主机提供数据服务的磁盘数两个参数中的最小值，同时要保证主机有资源做其它任务。

如果瓶颈在客户端处理，但是客户端还有空闲资源，那建议不要增加SQL的并行，而是用一个进程取回数据后在客户端起多个进程处理即可，进程数根据客户端CPU核数计算。

如果瓶颈在客户端网络，那建议做数据压缩或者增加多个客户端，采用map reduce的架构处理。

如果瓶颈在服务器网络，那需要增加服务器的网络带宽或者在服务端将数据压缩后再处理了。

5.2、数据库并行处理
数据库并行处理是指客户端一条SQL的请求，数据库内部自动分解成多个进程并行处理，如下图所示：

并不是所有的SQL都可以使用并行处理，一般只有对表或索引进行全部访问时才可以使用并行。数据库表默认是不打开并行访问，所以需要指定SQL并行的提示，如下所示：

select /*+parallel(a,4)*/ * from employee;

并行的优点：

使用多进程处理，充分利用数据库主机资源（CPU,IO），提高性能。

并行的缺点：

1、单个会话占用大量资源，影响其它会话，所以只适合在主机负载低时期使用；

2、只能采用直接IO访问，不能利用缓存数据，所以执行前会触发将脏缓存数据写入磁盘操作。

注：

1、并行处理在OLTP类系统中慎用，使用不当会导致一个会话把主机资源全部占用，而正常事务得不到及时响应，所以一般只是用于数据仓库平台。

2、一般对于百万级记录以下的小表采用并行访问性能并不能提高，反而可能会让性能更差。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yzsind/archive/2010/12/06/6059209.aspx

本文链接

强烈推荐：240多个jQuery插件

2010-10-21T08:38:00Z

概述

jQuery 是继 prototype 之后又一个优秀的 Javascript 框架。其宗旨是—写更少的代码,做更多的事情。它是轻量级的 js 库(压缩后只有21k) ，这是其它的 js 库所不及的，它兼容 CSS3，还兼容各种浏览器（IE 6.0+, FF 1.5+, Safari 2.0+, Opera 9.0+）。 jQuery 是一个快速的，简洁的 javaScript 库，使用户能更方便地处理 HTML documents、events、实现动画效果，并且方便地为网站提供 AJAX 交互。 jQuery 还有一个比较大的优势是，它的文档说明很全，而且各种应用也说得很详细，同时还有许多成熟的插件可供选择。 jQuery 能够使用户的 html 页保持代码和 html 内容分离，也就是说，不用再在 html 里面插入一堆js来调用命令了，只需定义 id 即可。今天在Kollermedia.at上发现了一篇JQuery插件列表的文章，特推荐如下。

文件上传(File upload)

Ajax File Upload.
jQUploader.
Multiple File Upload plugin.
jQuery File Style.
Styling an input type file.
Progress Bar Plugin.

表单验证(Form Validation)

jQuery Validation.
Auto Help.
Simple jQuery form validation.
jQuery XAV - form validations.
jQuery AlphaNumeric.
Masked Input.
TypeWatch Plugin.
Text limiter for form fields.
Ajax Username Check with jQuery.

表单－选取框(Form - Select Box stuff)

jQuery Combobox.
jQuery controlled dependent (or Cascadign) Select List.
Multiple Selects.
Select box manipulation.
Select Combo Plugin.
jQuery - LinkedSelect
Auto-populate multiple select boxes.
Choose Plugin (Select Replacement).

表单基本、输入框、选择框等(Form Basics, Input Fields, Checkboxes etc.)

jQuery Form Plugin.
jQuery-Form.
jLook Nice Forms.
jNice.
Ping Plugin.
Toggle Form Text.
ToggleVal.
jQuery Field Plugin.
jQuery Form’n Field plugin.
jQuery Checkbox manipulation.
jTagging.
jQuery labelcheck.
Overlabel.
3 state radio buttons.
ShiftCheckbox jQuery Plugin.
Watermark Input.
jQuery Checkbox (checkboxes with imags).
jQuery SpinButton Control.
jQuery Ajax Form Builder.
jQuery Focus Fields.
jQuery Time Entry.

时间、日期和颜色选取(Time, Date and Color Picker)

jQuery UI Datepicker.
jQuery date picker plugin.
jQuery Time Picker.
Time Picker.
ClickPick.
TimePicker.
Farbtastic jQuery Color Picker Plugin.
Color Picker by intelliance.fr.

投票插件(Rating Plugins)

jQuery Star Rating Plugin.
jQuery Star Rater.
Content rater with asp.net, ajax and jQuery.
Half-Star Rating Plugin.

搜索插件(Search Plugins)

jQuery Suggest.
jQuery Autocomplete.
jQuery Autocomplete Mod.
jQuery Autocomplete by AjaxDaddy.
jQuery Autocomplete Plugin with HTML formatting.
jQuery Autocompleter.
AutoCompleter (Tutorial with PHP&MySQL).
quick Search jQuery Plugin.

编辑器(Inline Edit & Editors)

jTagEditor.
WYMeditor.
jQuery jFrame.
Jeditable - edit in place plugin for jQuery.
jQuery editable.
jQuery Disable Text Select Plugin.
Edit in Place with Ajax using jQuery.
jQuery Plugin - Another In-Place Editor.
TableEditor.
tEditable - in place table editing for jQuery.

多媒体、视频、Flash等(Audio, Video, Flash, SVG, etc)

jMedia - accessible multi-media embedding.
JBEdit - Ajax online Video Editor.
jQuery MP3 Plugin.
jQuery Media Plugin.
jQuery Flash Plugin.
Embed QuickTime.
SVG Integration.

图片(Photos/Images/Galleries)

ThickBox.
jQuery lightBox plugin.
jQuery Image Strip.
jQuery slideViewer.
jQuery jqGalScroll 2.0.
jQuery - jqGalViewII.
jQuery - jqGalViewIII.
jQuery Photo Slider.
jQuery Thumbs - easily create thumbnails.
jQuery jQIR Image Replacement.
jCarousel Lite.
jQPanView.
jCarousel.
Interface Imagebox.
Image Gallery using jQuery, Interface & Reflactions.
simple jQuery Gallery.
jQuery Gallery Module.
EO Gallery.
jQuery ScrollShow.
jQuery Cycle Plugin.
jQuery Flickr.
jQuery Lazy Load Images Plugin.
Zoomi - Zoomable Thumbnails.
jQuery Crop - crop any image on the fly.
Image Reflection.

Google地图（Google Map）

jQuery Plugin googlemaps.
jMaps jQuery Maps Framework.
jQmaps.
jQuery & Google Maps.
jQuery Maps Interface forr Google and Yahoo maps.
jQuery J Maps - by Tane Piper.

游戏(Games)

Tetris with jQuery.
jQuery Chess.
Mad Libs Word Game.
jQuery Puzzle.
jQuery Solar System (not a game but awesome jQuery Stuff).

表格等(Tables, Grids etc.)

UI/Tablesorter.
jQuery ingrid.
jQuery Grid Plugin.
Table Filter - awesome!.
TableEditor.
jQuery Tree Tables.
Expandable “Detail” Table Rows.
Sortable Table ColdFusion Costum Tag with jQuery UI.
jQuery Bubble.
TableSorter.
Scrollable HTML Table.
jQuery column Manager Plugin.
jQuery tableHover Plugin.
jQuery columnHover Plugin.
jQuery Grid.
TableSorter plugin for jQuery.
tEditable - in place table editing for jQuery.
jQuery charToTable Plugin.
jQuery Grid Column Sizing.
jQuery Grid Row Sizing.

统计图(Charts, Presentation etc.)

jQuery Wizard Plugin .
jQuery Chart Plugin.
Bar Chart.

边框、圆角、背景(Border, Corners, Background)

jQuery Corner.
jQuery Curvy Corner.
Nifty jQuery Corner.
Transparent Corners.
jQuery Corner Gallery.
Gradient Plugin.

文字和超链接(Text and Links)

jQuery Spoiler plugin.
Text Highlighting.
Disable Text Select Plugin.
jQuery Newsticker.
Auto line-height Plugin.
Textgrad - a text gradient plugin.
LinkLook - a link thumbnail preview.
pager jQuery Plugin.
shortKeys jQuery Plugin.
jQuery Biggerlink.
jQuery Ajax Link Checker.

鼠标提示（Tooltips）

jQuery Plugin - Tooltip.
jTip - The jQuery Tool Tip.
clueTip.
BetterTip.
Flash Tooltips using jQuery.
ToolTip.

菜单和导航(Menus, Navigations)

jQuery Tabs Plugin - awesome! . [demo nested tabs.]
another jQuery nested Tab Set example (based on jQuery Tabs Plugin).
jQuery idTabs.
jdMenu - Hierarchical Menu Plugin for jQuery.
jQuery SuckerFish Style.
jQuery Plugin Treeview.
treeView Basic.
FastFind Menu.
Sliding Menu.
Lava Lamp jQuery Menu.
jQuery iconDock.
jVariations Control Panel.
ContextMenu plugin.
clickMenu.
CSS Dock Menu.
jQuery Pop-up Menu Tutorial.
Sliding Menu.

http://stilbuero.de/jquery/tabs_3/

幻灯、翻转等(Accordions, Slide and Toggle stuff)

jQuery Plugin Accordion.
jQuery Accordion Plugin Horizontal Way.
haccordion - a simple horizontal accordion plugin for jQuery.
Horizontal Accordion by portalzine.de.
HoverAccordion.
Accordion Example from fmarcia.info.
jQuery Accordion Example.
jQuery Demo - Expandable Sidebar Menu.
Sliding Panels for jQuery.
jQuery ToggleElements.
Coda Slider.
jCarousel.
Accesible News Slider Plugin.
Showing and Hiding code Examples.
jQuery Easing Plugin.
jQuery Portlets.
AutoScroll.
Innerfade.

拖放插件(Drag and Drop)

UI/Draggables.
EasyDrag jQuery Plugin.
jQuery Portlets.
jqDnR - drag, drop resize.
Drag Demos.

XML XSL JSON Feeds

XSLT Plugin.
jQuery Ajax call and result XML parsing.
xmlObjectifier - Converts XML DOM to JSON.
jQuery XSL Transform.
jQuery Taconite - multiple Dom updates.
RSS/ATOM Feed Parser Plugin.
jQuery Google Feed Plugin.

浏览器(Browserstuff)

Wresize - IE Resize event Fix Plugin.
jQuery ifixpng.
jQuery pngFix.
Link Scrubber - removes the dotted line onfocus from links.
jQuery Perciformes - the entire suckerfish familly under one roof.
Background Iframe.
QinIE - for proper display of Q tags in IE.
jQuery Accessibility Plugin.
jQuery MouseWheel Plugin.

对话框、确认窗口(Alert, Prompt, Confirm Windows)

jQuery Impromptu.
jQuery Confirm Plugin.
jqModal.
SimpleModal.

CSS

jQuery Style Switcher.
JSS - Javascript StyleSheets.
jQuery Rule - creation/manipulation of CSS Rules.
jPrintArea.

DOM、AJAX和其它JQuery插件（DOM, Ajax and other jQuery plugins）

FlyDOM.
jQuery Dimenion Plugin.
jQuery Loggin.
Metadata - extract metadata from classes, attributes, elements.
Super-tiny Client-Side Include Javascript jQuery Plugin.
Undo Made Easy with Ajax.
JHeartbeat - periodically poll the server.
Lazy Load Plugin.
Live Query.
jQuery Timers.
jQuery Share it - display social bookmarking icons.
jQuery serverCookieJar.
jQuery autoSave.
jQuery Puffer.
jQuery iFrame Plugin.
Cookie Plugin for jQuery.
jQuery Spy - awesome plugin.
Effect Delay Trick.
jQuick - a quick tag creator for jQuery.
Metaobjects.
elementReady.

英文：http://www.kollermedia.at/archive/2007/11/21/the-ultimate-jquery-plugin-list/

作者：TerryLee
出处：http://terrylee.cnblogs.com

本文链接

DotNet 开发小结

2010-09-13T11:58:00Z

2010-09-13T11:58:00Z2010-09-13T11:58:00Zpxuanhttp://www.cnblogs.com/eugenewu0808/

本文链接

常见负载均衡实现

2010-08-20T07:25:00Z

http://www.cnblogs.com/highriver/archive/2010/06/22/1762573.html

理解负载均衡，首先要理解转移与转发的区别：

转移与转发就象客户与外包公司是否需要直接接触的场景一样，如果直接与外包公司接触就是转移。如果通过接包人接触。客户与外包公司之间透明，就是转发。
转移：数据包从客户端转移到实际服务器，需要知道实际服务器的地址。
转发：数据包只须从客户端发送到代理服务器或DNAT服务器上，再由它们转发到实际服务器。当数据包发给代理或DNAT时，客户端就认为数据包已经发送给实际服务器上。当实际服务器接收到代理或DNAT发来的包，实际服务器就认为数据包就是来自客户端。

转移只需要客户端，实际服务器参与
转发需要客户端代理或DNAT 实际服务器参与

一.DNS的负载均衡：
DNS的负载均衡是一种［转移］。而不是［转发］。

二.反向代理负载均衡：
对于客户端，实际服务器是基于WEB服务器或一些专门的代理varnish就是工作在一种转发的模式下。转发的优势，在七层工作，可以针对每个http请求定制负载。可以配置负载的权重。可以将调度策略落实到每一个 HTTP 请求。

反向代理服务器工作在 HTTP 层面,对于所有 HTTP 请求都要亲自转发,可谓是大事小事亲历亲为，可控也带来了劣势。就是可扩展会限制。
反向代理服务器的另一个特点就是可以根据ip进行hash,从而做到sticky session，即一个客户的连续请求被转发到同一台backend。
事实上,在后端服务器上保存 Session 数据和本地化缓存是bad smell.它使得后端服务器显得过于个性化,以至于和整个系统格格不入,如果允许的话,我们应该尽量避免这样的设计,比如采用分布式 Session 或者分布式缓存等,让后端服务器的应用尽量与本地无关,也可更好地适应环境。
解决如下：
1.SNA.
2.分布式session：memcached/terracotta

三.DNAT负载均衡：

DNAT与DNS协作的方式：
DNS是翻译域名为IP。DNAT是用来修改包。
因为DNAT转发都是通过IP进行的，而不是通过域名。
如果客户端通过域名访问DNAT服务器，首先会通过DNS将域名翻译成IP地址。然后再把客户端的数据包发送到DNAT服务器上。如果客户端直接使用IP地址。连DNS的翻译都免了，直接找的是DNAT服务器。然后再通过DNAT来修改数据包地址及端口来实现［转发］到实际服务器。

DNAT服务器：与动态代理服务器干的一样的工作：［转发］。
DNAT的工作原理：修改数据包目标地址及端口。
DNAT是根据内核的Netfilter包及规则配置iptables（类似于数据文件）来完成对数据包的目标地址及端口进行修改。
注意：
1.Netfilter与iptables是DNAT实现修改包的工具，是DNAT最重要的组成部分。
2.DNAT表示了原理。其实DNAT服务器有时候就是NAT服务器。所以，简称为NAT方式实现IP层的负载均衡。

DNAT的缺点：
iptables 似乎只能按照我们的规则来干活,没有调度器应该具备的调度能力和调度策略。

四：LVS负载均衡
熟悉了 Netfilter/iptables 的机制后。
理解 IPVS(IP Virtual Server)就一点也不难了,它的工作性质类似于 Netfilter 模块,也工作在 Linux 内核中,但是它更专注于实现 IP 负载均衡。
IPVS 不仅可以实现基于 NAT 的负载均衡,同时还包括后面要介绍的直接路由和 IP 隧道等负载均衡。IPVS模块已经内置到 Linux 2.6.x 内核中,这意味着使用 Linux 2.6.x 内核的服务器将无须重新编译内核就可以直接使用它。
当然,IPVS 也需要有与DNAT类似的管理工具,即ipvsadm

VIP是使用LINUX的内核进行负载均衡：
[反向代理服务器]作为负载均衡调度器的工作机制,其本身的开销已经严重制约了这种框架的可扩展性,从而也限制了它的性能极限。
能否在 HTTP 层面以下实现负载均衡呢?答案是肯定的。回忆一下网络分层模型,事实上,在数据链路层(第二层) 、网络层(第三层)以及传输层(四层)都可以实现不同机制的负载均衡,但有所不同的是,这些负载均衡调度器的工作必须由 Linux 内核来完成,因为我们希望网络数据包在从内核缓冲区进入进程用户地址空间之前,尽早地被转发到其他实际服务器上,没错,Linux 内核当然可以办得到,随后我们会介绍位于内核的 Netfilter 和 IPVS,而用户空间的应用程序对此却束手无策。
好处：
1.因为可以将调度器工作在应用层以下,这些负载均衡系统可以支持更多的网络服务协议,比如 FTP、SMTP、DNS,以及流媒体和 VoIP 等应用。
2.调度策略

LVS的三种配置：
LVS－NAT：与DNAT达到的结果一样，实现方式不一样。
LVS－DR：返回的内容不需要再经过调度器（NAT服务器），直接发给客户端，这样可以减轻调度器的带宽压力，适用于响应的内容远远大于请求的内容时（其实，基本适用于80％的场景。通常响应的内容比请求都要大很多。并不一定是视频服务等）
LVS－TUN：调度器（NAT服务器）可以与实际服务器不在同一个WAN网段，比如应用是分布式的。调度器通过 IP 隧道技术来转发请求到实际服务器,所以实际服务器也必须拥有合法的 IP 地址。

本文链接

[转]DDD/Transaction Script/Active Record架构解惑

2010-08-20T06:25:00Z

http://www.cnblogs.com/yanyangtian/archive/2010/07/13/1776355.html

架构设计解惑

架构设计解惑

　　前言:之前的文章,很多朋友发来了反馈,从反馈中也看出了一些问题,一个最明显的问题就是:当我提到DAL的实现的时候,一些朋友就问:DAL中采用了Repository模式吗? 初一看起来,可能认为这个问题没有什么,其实仔细的想想就会发现,确实在问题的背后隐藏的了另外的一个问题.

本篇的议题如下:

1.       问题的阐述

2.       设计方法

3.       总结

　　1.       问题的阐述

在项目中,我们一般都是分层,大家最熟悉的就是UI,BLL,DAL层,或者在加上一个Services服务层.一般的项目就这样设计了.由于越来越多的公司,社区倡导领域驱动设计(DDD),于是,又有了项目的分层的方式,DDD设计中的一些概念也引入了: Presentation, Service, Domain, Repository. 而且一般来说,有下面的对应关系:

Presentation

UI

Domain

BLL

Repository

DAL

　　但是在开发的时候,一会儿在项目中建立一个Domain的类库,一会儿又在项目建立DAL,最后的情况就是:UI, Domain, DAL等等. 其实这倒是没有什么,说到底只是一个名称的问题,但是在只后面隐藏的问题就是:对DDD的不了解,很多的时候只是注重了”形”,而没有领会到”神”.

　　在项目中不是建立了名称为Presentation, Domain, Repository的类库,这个项目就是DDD开发了,不是这样的.本来在分层的时候采用UI,BLL,DAL,自己是很熟悉的,但是这样一搅和, 最后反而把概念搞复杂了.

　　而且,在项目中,是采用原来朴实的那种三层,还是采用DDD开发,是要经过思考的,不是那DDD的方法来套.也就是说,不要为了DDD而DDD.就像当初我们学习设计模式一样,没有必要在写代码的过程中为了设计模式而设计模式.

　　2.       设计方法

到底是采用DDD还是那种朴实的三层,主要取决与业务层的设计和系统的复杂度.

　　如果系统确实很复杂,业务逻辑相当的复杂,那么建议采用DDD,因为DDD的引入就是用解决复杂性的.因为采用DDD的方法来设计业务逻辑层,那么业务逻辑层就只是关注业务逻辑的处理,至于怎么存储和获取数据,丝毫不关心,所以基于这个原因,在DDD中就引入了Repository的概念,Repository就是来辅助业务逻辑层处理数据的.

　　虽然我一直在提”朴实的三层”,其实DDD和它之间没有什么很明显的划分了,这里我之所以特意的把他们划分出来,主要就是因为我们在项目开发中一般是三层(或者N层),这里提出主要是为便于后面讲述一些问题.

下面就开始讲述一些业务逻辑层设计方法,相信大家看完之后,很多的疑惑就迎刃而解了.

业务层的设计方法有三种:Transaction Script, Active Record和Domain Model.

看过Flower的<<企业架构模式>>一书的朋友应该对上面的三个词语很熟悉,在书中,这些概念讲的确实很精炼,可能因为精炼,所以理解起来就不是很容易.

在本篇文章中,就涉及到了这些知识,只有把这些点讲清楚了,之前的问题就能解决.

如果熟悉这些概念的朋友,也不妨看看,大家可以交流!

首先来看看Transaction Script(之所以没有翻译为中文，因为翻译后的中文意思很容易让人产生误导)

其实Transaction Script就是过程化的设计方式，最直观表现就是一个个的方法，每个方法做一个业务的流程。我们来看下面一个例子。例子的背景就是在电子商务网站中订单的处理流程。

public class OrderManager
    {
        public void PlaceOrder(OrderDTO order)
        {
            // Validate order based on business rules
            // Check for stock availablity on items ordered
            // Add the order to the database
            // Set the order id on the OrderDTO object
        }
        public bool CancelOrder(Guid orderId)
        {
            // Retrieve order from database
            // Determine if the order can be canceled
            // if order can be canceled, set as canceled
            // return true/false if order was canceled
        }
        public bool AddItemToOrder(Guid orderId, OrderItemDTO ItemToAdd)
        {
            // Retrieve order from database
            // Determine if the item can be added to the order
            // Add a new item row in the database
            // return true/false if item was added to the order
        }
        public bool ProcessOrder(Guid orderId)
        {
            // Check to ensure this order can be processed.
            // Validate order based on business rules
            // Update the stock levels of products ordered
            // return true/false if order was processed
        }
    }

在上面的代码中，所有和订单处理有关的逻辑都写在OrderManager类中。类中的每一个方法就对应业务逻辑中的一个流程或者说对应一个use case，例如：CancelOrder就是取消订单。

通过Transaction Script的方式来组织业务逻辑，一个很好的好处就是直观，很容易理解代码在做什么。如果有新的流程来了，再加一个方法就行了。

同时，这种组织方式的弊端就在于，当系统中的业务变得多而且复杂的时候，那么这样的方法就开始变多，最后的结果就是一个类中有成百上千个方法。而且这些方法中，除了一些基本的验证可以提取为方法重用，其他的流程控制代码在很多的地方要重写，特别是当有两个流程差不多的时候，代码不可避免的重新写。于是，这样的类开始变得庞大而难以管理。

Active Record

这种组织方式已经是我们最熟悉的了。

在很多的项目中，我们的业务实体类基本和数据库中表是一一对应的，例如一个Order业务类就是代表了数据库中的Order表。而且在平时项目中，”朴实的三层(N层)”，一般都是基于这种方式在组织逻辑。

这种方式的最大的区别就是每个业务类自己负责自己的数据存取，也就是说在业务类中包含了业务逻辑的处理和数据的存取。

例如：

public class Order
{
    private Guid _id;
    private DateTime _creationDate;
    private int _shippingMethod;
    private int _status;
    private List<OrderItems> _orderItems;
    public Guid Id
    {
        get { return _id; }
        set { _id = value; }
    }

    public List<OrderItems> OrderItems
    {
        get { return _orderItems; }
        set { _orderItems = value; }
    }
    // Business Logic
    public void Place()
    {
        // Validate order based on business rules to ensure it is in
        // a good state to add to the database
        // Check for stock availablity on items ordered
        this.Add();
    }
    public void Cancel()
    {
        // Check to ensure this order can be canceled.
        this.Status = Status.Cancelled();
        this.Save();
    }

    public void ProcessOrder()
    {
        // Check to ensure this order can be processed.
        // Validate order based on business rules
        // Udpate the stock levels of products ordered
    }

    // Data Access Methods
    public void Save()
    {
        // Code to persist changes to the database
    }

    public void Add()
    {
        // Code to Add this object to the database
    }

    public void Delete()
    {
        // Code to remove this object from the database
    }

    public static List<Order> FindAll()
    {
        // Code to retrive all Orders from the database
    }
    public static Order FindBy(Guid id)
    {
        // Code to retrive a specific Order from the database
    }
}

上面的代码中，Order类包含了业务逻辑处理的代码，如Cancel, Process。通过这些方法也调用了数据访问代码来保存数据。

如果在开发的项目中，业务类和数据表是一一对应的关系，例如在开发博客或者论坛，Active Record方式就很合适。

相信很多的项目都是基于这个方式在开发和组织逻辑层，这个方式最大的弊端就是：数据库表只要改动，那么业务逻辑层动，而且这种变动会一直波及到了UI那端。

Domain Model

通过用这种方式来组织业务层的时候，业务层就只是关注把现实中的概念转换为相应的业务逻辑模型，不关注其他的方面。例如，在电子商务网站开发中，一些概念就被建模表示为一个个的业务模型(也就是业务类)，Order, Shopping Cart, Customer等。而且和Active Record最大的区别就是：Domain Model中的业务类不是和表一一对应的，下图就是一个很好的例子：

而且最主要的特点就是：每个业务类包含了很多的业务验证，状态跟踪等。职责很单一，便于维护和理解。

示例代码如下：

public class Order
{
    private Guid _id;

    public Guid Id
    {
        get { return _id; }
        set { _id = value; }
    }

    public float ShippingCost()
    {
        return ShippingMethod.ShippingCostTo(this.DispatchAddress, this.ItemsTotalWeight());
    }

    public float Total()
    {
        return DiscountOffer.TotalPriceWithDiscountOfferAppliedTo(
        this.Items, ShippingCost());
    }

    public void Process()
    {
        if (this.CanProcess())
        {
        // Charge the card
        Customer.Card.Charge(this.Total());
        // Set the status of the order
        this.Status = Status.Shipped;
        // Adjust the stock levels
        foreach (OrderItem item in Items)
        {
            item.Product.DecreaseStockBy(item.QtyOrdered);
        }
        else
        {
            throw new InvalidOrderStateForOperationException(
            String.Format(
            "Order {0} cannot be processed in its current state {1}",
            this.Id, this.Status.ToString());
        }
    }

    public bool CanProcess()
    {
        if (!this.Status == Status.Shipped && !this.Status = Status.Cancelled)
        {
            return (this.HasEnoughStockFor(me.Items) &&

            GetBrokenRules.Count() == 0);
        }
        else
        {
            return false;
        }
    }

    public List<BrokenBusinessRule> GetBrokenRules()
    {
        List<BrokenBusinessRule> brokenRules = new List<BrokenBusinessRule>();
        if (Customer == null)
            brokenRules.Add(new BrokenBusinessRule()
            {
                Property = "Customer",
                Rule = "An Order must have a Customer"
            });
        else if (Customer.GetBrokenRules().Count > 0)
        {
            AddToBrokenRulesList(brokenRules, Customer.GetBrokenRules());
        }
        if (DispatchAddress == null)
            brokenRules.Add(new BrokenBusinessRule()
            {
                Property = "DispatchAddress",
                Rule = "An Order must have a Dispatch Address"
            });
        else if (DispatchAddress.GetBrokenRules().Count > 0)
        {
            AddToBrokenRulesList(brokenRules,
            DispatchAddress.GetBrokenRules());
        }
        // ......
        return brokenRules;
    }
}

上面的代码只是Order业务类的一部分代码，但是从代码中可以看出，这个类中包含了很丰富的业务逻辑。例如，在Process方法中，处理了下面的流程：

1．  调用CanProcess 方法来进行下面的验证：

a.       Order的是否处于合适的可以被处理的状态

b.       在Order中订购的物品是否有足够的库存

2． customer用户给这个order付款。至于怎么付款，这个逻辑就包含在了card类中。

3．然后，对产品的库存进行更新。

可以看出，采用Domain Model方式很适合来来组织复杂的业务逻辑，而且代码也很容易阅读和理解(如果在加上重构)。

　　3.       总结

通过上面的一些分析和解释，不知道大家是否现在已经清楚：之前提出的问题如何解决。

一个建议就是：不要太形式化，根据项目的实际情况来。这句话可以使相当于废话，但是很多的情况确实是这样的，DDD不是万能的，Transaction Script和Active Record也有它们的优势，合适就好。

谢谢各位！
本文链接