一、会话信道（Sessionful Channel） V.S. 数据报信道（Datagram Channel）

WCF通过信道栈实现了消息的编码、传输及基于某些特殊功能对消息的特殊处理，而绑定对象是信道栈的缔造者，不同的绑定类型创建出来的信道栈具有不同的特性。就对会话的支持来讲，我们可以将信道分为以下两种：

• 会话信道（Sessionful Channel）：会话信道确保客户端和服务端之间传输的消息能够相互关联，但是信道的错误（Fault）会影响后续的消息交换；
• 数据报信道（Datagram Channel）：即使在同一个数据报信道中，每次消息的交换都是相互独立，信道的错误也不会影响后续的消息交换。

对于绝大部分绑定类型（BasicHttpBinding除外），在默认的情况下创建的都是会话信道。对于WCF客户端来说，如果进行基于会话信道的服务调用，有一些问题需要引起足够的重视，如果使用不当，不但影响客户端本身的服务调用，还会对服务处理请求的吞吐量造成很大的影响。

二、服务代理的关闭与并发会话（Concurrent Sessions）的限制

基于会话信道服务调用须要注意的第一个问题和WCF流量限制有关，为了使读者对这个问题先有一个直观认识，我们照例通过一个简单的实验来重现须要解决的问题。本例使用我们熟悉的计算服务例子，在服务寄宿的时候采用WsHttpBinding，下面是客户端程序。

Binding binding = new WsHttpBinding();
EndpointAddress address = new EndpointAddress("http://127.0.0.1:9999/calculateservice");
ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>(binding, address);
for (int i = 1; i <= 20; i++)
{
    try
    {
        ICalculator calculator = channelFactory.CreateChannel();
        Console.WriteLine("{3}: x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2), i);
    }
    catch (Exception ex)
    {
        Console.WriteLine("{0}t: {1}", i, ex.Message);
    }
}

输出结果：

1 ： x + y = 3 when x = 1 and y = 2
2 ： x + y = 3 when x = 1 and y = 2
......
10： x + y = 3 when x = 1 and y = 2
11： x + y = 3 when x = 1 and y = 2
12：请求通道在等待 00:00:59.9840000以后答复超时。增加传递给请求调用的超时值，或者增加绑定上的 SendTimeout 值。分配给此操作的时间可能是更长超时的一部分

从输出的结果可以看出，虽然在代码中我们通过一个for循环进行了20次服务调用，但是真正成功执行的仅仅有11次，第12次进行服务调用的时候，抛出Timeout异常。这种情况的出现源于WCF对并发会话数量的控制。说得具体点，WCF对一个ServiceHost所能处理的并发会话作了限制，在默认的情况下，允许的最大并发会话数量为10。

那么细心的读者马上会问一个问题，既然默认的并发会话数量为10，为什么上面的例子中，会有11次成功的并发服务调用呢？这是因为，服务端的信道监听器允许一个额外的会话信道。在很多情况下，11个并发会话肯定是不能满足具体的需求的，那么是否可通过相应的配置根据具体的需求灵活指定一个合适的最大并发会话数量呢？答案是肯定的，服务允许的最大并发会话可以通过ServiceThrottlingBehavior服务行为的MaxConcurrentSessions属性进行配置。在下面的配置中，将该值设为了20。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>  
    <system.serviceModel>       
        <behaviors>
            <serviceBehaviors>
                <behavior name="highConcurrencyBehavior">
                    <serviceThrottling maxConcurrentSessions="20" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
         ... ...
    </system.serviceModel>
</configuration>

WCF对服务的并发会话的限制给WCF客户端提出了一个要求，那就是在服务代理不再使用的情况下，应该及时将其关闭。基于服务代理对象的会话会随着服务代理的关闭而关闭。服务端在处理客户端请求的时候，如果当前并发的会话数量超过了所允许的范围，后续的请求将会被放入等待队列，以等待现有会话的结束。对于客户端来说，服务调用在允许的超时时限（默认1分钟）内还未接收到回复，则会抛出一个TimeoutException异常，如例子所表现的一样。如果能够及时地关闭服务代理对象，即使是2000次调用都没有问题，如下所示：

Binding binding = new WSHttpBinding();
EndpointAddress address = new EndpointAddress("http://127.0.0.1:9999/calculateservice");
ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>(binding, address);
for (int i = 1; i <= 2000; i++)
{
    ICalculator calculator = channelFactory.CreateChannel();
    Console.WriteLine("{3}: x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2), i);
     (calculator as ICommunicationObject).Close();
}

输出结果：

1 ： x + y = 3 when x = 1 and y = 2
2 ： x + y = 3 when x = 1 and y = 2
......
1999： x + y = 3 when x = 1 and y = 2
2000： x + y = 3 when x = 1 and y = 2

三、服务代理的关闭与否对数据报信道没有影响

上面讲的是对最大会话的限制，实际也可以说成是对最大会话信道的限制，那么对于非会话信道是否也有此限制呢？实践出真知，照例通过具体的例子来说明问题。我们知道绑定是信道的创建者，信道的特性通过组成绑定的元素（绑定元素）决定，所以信道对会话支持的特性也不例外。以上面例子使用的WsHttpBinding为例，只有WsHttpBinding的安全（Security）或可靠会话（Reliable Session）开启的情况下，创建的信道才具有会话的特性，否则创建出来的信道是不能支持信道的。在默认的情况下，WsHttpBinding的安全模式（SecurityMode）为基于消息的安全，所以创建出来的信道自动被赋予了会话的特性。

为了验证在非会话信道的情况下，WCF最大并发会话限制是否存在，我们对上面的代码稍加修改，在创建WsHttpBinding的时候，将安全模式设为SecurityMode.None（当然，在进行服务寄宿的时候，WsHttpBinding也须要进行相同的设置）。通过最终输出结果可以看出，MaxConcurrentSessions的限制不适合非会话邦定。

Binding binding = new WSHttpBinding(SecurityMode.None);
EndpointAddress address = new EndpointAddress("http://127.0.0.1:9999/calculateservice");
ChannelFactory<ICalculator> channelFactory = new ChannelFactory<ICalculator>(binding, address);
for (int i = 1; i <= 2000; i++)
{
    ICalculator calculator = channelFactory.CreateChannel();
    Console.WriteLine("{3}: x + y = {2} when x = {0} and y = {1}", 1, 2, calculator.Add(1, 2), i);
}

输出结果：

1 ： x + y = 3 when x = 1 and y = 2
2 ： x + y = 3 when x = 1 and y = 2
......
1999： x + y = 3 when x = 1 and y = 2
2000： x + y = 3 when x = 1 and y = 2

P.S. 部分内容节选自《WCF技术剖析（卷1）》第八章

WCF技术剖析系列：

WCF技术剖析之一：通过一个ASP.NET程序模拟WCF基础架构
WCF技术剖析之二：再谈IIS与ASP.NET管道
WCF技术剖析之三：如何进行基于非HTTP的IIS服务寄宿
WCF技术剖析之四：基于IIS的WCF服务寄宿（Hosting）实现揭秘
WCF技术剖析之五：利用ASP.NET兼容模式创建支持会话（Session）的WCF服务
WCF技术剖析之六：为什么在基于ASP.NET应用寄宿（Hosting）下配置的BaseAddress无效
WCF技术剖析之七：如何实现WCF与EnterLib PIAB、Unity之间的集成
WCF技术剖析之八：ClientBase<T>中对ChannelFactory<T>的缓存机制
WCF技术剖析之九：服务代理不能得到及时关闭会有什么后果?

　 　Windows Communication Foundation (WCF) 是 Microsoft 为构建面向服务的应用程序而提供的统一编程模型（摘自MSDN），在分布式环境下的安全问题尤为重要，如果你觉得使用了WCF默认的安全措施可以让你高枕 无忧，那明天你可就以回家种田了，当然，对于学习来说，足够了~，但我们讲的是真正的项目应用，WCF在各种协议下的安全提供和保证是不尽相同的。

　　背景

　　在上一篇X509证书介绍后，相信大家对怎么使用X509证书在WCF的安全策略中有一定的了解，本章主要讲述在WCF的消息安全模式下的服务器对客户端基于自定义用户名和密码的身份验证模式。当所有内置 UserNamePassword 验证模式均不符合应用程序的要求时，你可以能过继承 System.IdentityModel.Selectors.UserNamePasswordValidator 抽象类，并重写其Validate方法来实现自己的用户名密码验证程序，实际上，内置的用户名密码验证方式比自定义的用户名密码验证方式要可靠得多，因为自定义的用户名密码验证程序任何人都可以构造，但是标准的用户名密码验证方式刚是将用户提供的用户名密码映射到windows账户，所以，如果映射失败，意味着验证不通过，以下示例在服务器端启用自定义的用户名密码验证程序，客户端在调用服务前需要提供访问服务所需要的用户名密码，并在EndpointIdenty中向服务器标识自己是合法用户，具体标识参见本系列第二章：WCF安全之EndPointIdentity。如果服务器验证通过，将向客户端返回一个从数据库查询到的xml列(xElement对象），并将内容打印到控制台。

　　开始吧

 1、实现自定义用户名密码方式有哪些要求？

如上面的所讲，首先，我们需要建立一个类，来继承自System.IdentityModel.Selectors.UserNamePasswordValidator抽象类，并重其validate方法，代码比较简单，当然，这只是用于演示作用，如果是在实际的项目中，你完全可以将用户名密码存储在持久化介质上，请看实现：

public class CustomUserPassword : UserNamePasswordValidator
    {
        public override void Validate(string userName, string password)
        {
            if (userName != "admin" || password != "admin")
            {
                throw new SecurityNegotiationException("验证用户名和密码时，未通过检测");
            }
        }
   }

 2、配置安全策略和模式

你可以在代码或者在配置文件中完成此安全策略实现过程，但是如果你是以代码方式实现，做之前请参考Artech的文章：[原创]WCF技术剖析之八：ClientBase中对ChannelFactory的缓存机制

 （请原谅我引用），配置文件实现如下：

在上面的过程中，我们的绑定配置中的安全策略必须是消息级别的安全，因为在传输级别中，是不提供用户名密码验证方式的。两种级别的的选择比较主要体现在安全和效率上,如果你的传输效率上没有什么问题，建议你选择第四种安全策略:TransportWithMessageCredential，TransportWithMessageCredential的好处是既提供安全传输，又保证消息加密，多好！相对来说还是比较简单的吧

3、证书的配置

启用消息安全策略必须配置x509证书，如果你不配置，服务启动将会收到一个异常：未提供安全证书。从上一章后，你也会觉得证书的配置都是比较简单的吧。所以这里也不用过多的费话了。

4、客户端调用服务

客户端在调用服务前设置一个用户名密码(此用户名密码你可动态配置，具体怎么动态你随意，可以是从持久介质上提取，也可以是用户输入），如下：

            UserDataClient client = new UserDataClient();
            client.ClientCredentials.UserName.UserName = "admin";
            client.ClientCredentials.UserName.Password = "admin";
            UserExtension usereE = client.GetUserExtension();
            XElement xe = client.GetUserExtensionXElement(null);
            Console.WriteLine("调用成功，开始打印消息.");
            Console.ForegroundColor = ConsoleColor.Red;
            Console.WriteLine("==================================");
            Console.WriteLine(xe.Value);

5、调用成功，控制台输出调用信息

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

后话：总体来说，自定义的用户名密码验证程序还是比较简单的，只是在效率上会有点问题。

 欢迎转载，但请注明出处－－梁规晓博客（http://www.cnblogs.com/viter/）！

本文列出了我在平时发现和积累的在面向对象编程中一些常见的“不够面向对象”的情况。

需要指出两点：

1.我们虽然列出了这九种情况，但并不是说出现了下面的情况就一定有问题了；我们希望读者这可以将其作为一种信号——仔细考虑一下是不是有更好的设计。

2.我们这里所说的面向对象的对象特指领域对象，即对象中包含领域数据和业务逻辑。

要确定不够面向对象的对象，首先要了解什么样的对象算是面向对象的，或者说好的面向对象的对象。关于面向对象设计的原则从不同的角度有很多种说法，我们这里采用一种比较简单的说法，即高内聚低耦合。所谓高内聚是指对象内的数据和方法是紧密相关的；所谓低耦合是指对象之间的依赖应当比较小，一个对象发生改变时不应当对不相关的对象产生影响。

一. 低内聚对象

我们把低内聚对象分为两种：一种是应该属于该对象的行为和数据分散到了其他对象中；另一种是该对象内部的行为和数据关系不够紧密。下面的1、2是属于前一种情况，3、4、5则是属于后一种情况。

1.贫血对象（Anemic Object）

瞧，那条贫血的狗！
故事的发生是这样的...
你养了一条宠物狗，在学习了面向对象编程之后，你打算为这条狗设计一个面向对象的系统。于是，根据你在C语言编程时的开发经验，结合你对“封装”二字的理解，你设计了这样一条狗：）这条狗由四部分组成：头、身子、腿和尾巴。

图 1

隔壁住着一位面向对象大师——法号鉴摩，你拿着设计图给他看。鉴摩大师只扫了一眼便说：
没有行为的对象不是好对象。

你似懂非懂地点了点头，正要往下说，大师挥了挥手说：“你明天再来罢。”

如果一个对象只有数据没有行为，它就是一个贫血对象，它只能被别人操作，或者作为某个操作的结果。对于简单的getter和setter，我们一般不将其归为领域行为。所以，上面这个对象就是一个贫血对象。这条狗还不会叫、不会跑，甚至还不会摇尾巴讨好你，真不知道你养这样一条狗干啥。

处理贫血对象时可以考虑把操作对象数据的行为移动到这个对象里面。对数据的封装只是面向对象中“封装”这个概念的一部分，我们的对象中除了封装数据还应当封装行为。

对于跟物理世界一一对应的对象，一般来说，我们不容易犯这样的错误。我们不妨来看一个实际工作中遇到的例子。在某个商店收银系统中，有一个对象叫做Product，它被设计成这样：

图 2

这个Product就是一个贫血类。单纯看这个类，是没有什么问题的。我们需要结合其他的类来观察。由于不同类型的产品打印方式不同，计税规则也不同，所以我们还有一个处理Product的类： 

图 3

我们可以明显的看出在这两个类的方法中存在非常相似的代码结构。如果Product的类型出现扩展，我们在这两个类（Product、ProductHandler）里面都需要做修改。这不符合面向对象编程中OCP原则。对于贫血对象的改进应当考虑将相关的行为移动到对象里面。 

图 4

如果我们发现相关行为移动到Product中去后ProductHandler所做的事情仅仅是将调用转发给Product，可以考虑将这个类消除。这里我们没有将Product形成继承结构，有兴趣的同学可以参考《重构》一书中的“以多态取代条件式”。

引申阅读：

1.《重构》一书种关于“以多态取代条件式”的内容。

2.管理者对象（Manager Object）

狗摇尾巴，还是摇狗尾巴，这是个问题！

第二天，你拿着另一个对象的类图去找鉴摩大师。你对鉴摩大师说：“我想大师昨天的意思是说我设计的Dog对象没有行为吧，其实所有的行为我都放到这个DogController对象中了。”

图 5

大师看了一下你的图，说道：“到底是狗摇尾巴，还是你在摇狗尾巴？”
你不解道：“这样有什么不同吗？”
鉴摩大师闭着眼睛说道：
不要问我，告诉我。
你更加迷惑了。不过你知道“知之为知之，不知Google之”的名言，所以你用大师的话为关键字Google了一下，还真有不少内容。
我们经常会看到一些类命名为：XxxxManager、XxxxHandler。这样类表面上是面向对象的，但其实质往往是面向过程的，只不过在外面包了一个Class而已。管理者对象往往是跟贫血对象成对出现的，业务数据保存在贫血对象中，而业务逻辑行为（或者从数据的角度来说也可以称为“对数据的操作”）则在管理者对象中。
管理者对象的问题是其中的各个方法之间的关系非常不明显，它们往往只是共享一个被操作的数据对象。去掉其中的几个方法，这个对象似乎还是一个完整的对象。上例中ProductHandler就是一个管理者对象的例子。

对于管理者对象，最基本的解决方法就是职责分组。首先创建或者从系统中找出相关的领域对象，尽量地将职责划分到多个领域对象中去。当管理者对象和贫血对象成对出现时，往往部分跟业务紧密相关的贫血对象既是领域对象。分层、数据字典都是常用的提取领域对象的方法。

3.储柜对象（Cabinet Object）

狗尾巴不见了！

第三天，你的朋友送了一条狗给你，并告诉你是在路边捡到的。所以，你需要在你的系统中再添加一只小狗啦。根据你丰富的内存管理方面的经验，你认为在内存中保留两个实例，实在是浪费，所以你扩展了一下API。你把新的设计方案交给鉴摩大师去看。

图 6

鉴摩大师冷漠地看了你一眼，仿佛看到一个陌生人似的，大师慢悠悠地说道：
今天的你不是昨天的你。
你一脸茫然地回到自己家里，突然发现狗尾巴不见了。谁调用了setTail(NULL)!

所谓储柜对象，是指它所有的数据都是可以通过setter动态设置的。也就是说getter返回什么或者对象的行为如何表现，完全取决于当时的设置了什么。这个对象中的数据，看起来就像临时分配的一块可读写的内存。

储柜对象的问题在于，我们编写和阅读代码的时候很难把握这种对象，因为其状态随时可能会被修改，而修改其状态的行为又分散在其他的地方。解决这个问题，可以先把储柜对象处理为Immutable Value，即在构造函数中传入必要的参数，只为那些可以动态修改的状态保留setter方法。如果有必要，还可以通过“以多态取代条件式”重构形成一个继承结构。

4.多管闲事的对象（Meddling Object）

你们家的狗会拿耗子吗？
你的朋友真好，第四天又送了一只猫给你。你已经开始庆幸自己学习了面向对象，这门支持“派生”的技术。你本来想直接从Dog派生一个Cat出来，觉得似乎有点问题。算了，你决定来个重新设计吧。为了用到面向对象里面最好用的技术——继承，你决定对狗和猫进行抽象，产生一个宠物（Pet）对象。好的，狗和猫有什么共同点呢？很快，结果出来了：

图 7

你甚至记得把Pet中makeSound和catchRat设计为抽象函数，让Dog和Cat分别实现。你高兴地拿给鉴摩大师去看。大师瞅了你一眼，问到：“你们家的狗会拿耗子？”
你狡黠一笑：“大师您看，我的catchRat是抽象函数，在Dog中实现地行为是‘do nothing’。”
“如果你们家有一百条狗，一百只猫呢？”大师说这句话的时候甚至连看都没看你一眼。过了一会儿，大师继续说道：
把变化的和不变的分离开。
你悻悻地回到家里，陷入了沉思...
对于一个对象而言，多管的闲事不属于自己的业务逻辑（虽然很可能有某种联系），我们应当把相关的代码完全隔离出去或者将相关职责委托给新的对象实现。隔离和委托的区别在于原对象是否持有新对象的引用。一般来说，委托的方式使用的更多一些，而且实现上也比较直观。对于上例而言，我们可以做如下的改进：

图 8

不恰当的抽象只是造成“多管闲事的对象”的原因之一。更常见的情况是，我们懒得为一个小功能创建一个新的类。比如下图就是一个实际工作中遇到的例子。

图 9

在计税的时候，我们需要做一些四舍五入的工作，这些职责本应该委托给一个工具类来完成。
引申阅读：
1.爱管闲事的对象违反了单一职责原则（SRP），容易导致设计不稳定。请参考有关SRP的文章。推荐《敏捷软件开发：原则、模式与实现》第8章。
2.《设计模式：可复用面向对象软件的基础》中关于在实现Composite模式时，安全性和透明性之间的权衡。

5.工具类（Utility Class）

你的设计越来越完善了！
第五天，你开始设计一些工具方法，给狗狗洗澡、喂食，可是这些方法放到哪儿呢？既然不能违反SRP原则，你决定每个工具方法设计一个类，但是看上去这些类也太简单了。  

图 10

你把自己的想法和顾虑告诉鉴摩大师，大师摇了摇头，随后说道：
物以类聚。易懂易维护才是我们的目标。

说工具类不够OO听上去有点奇怪，因为它根本不需要实例化，所以也不会形成真的对象。工具类的典型特征是里面的函数都是静态的。这些静态的函数之间往往没有必然的联系，甚至都不会共享数据，所以它们本质上是非内聚的。这里，并不是说不应当有工具类，而是工具类的角色很多时候都是提供一种转换或者值操作，不包含领域逻辑，因而不属于领域对象。把这些方法放到一个对象里面，就像给它们归归类而已。所以，如果一个类是工具类，就让它扮演好这个光荣的角色吧，别往里面放业务逻辑。如果有些转换明显跟业务逻辑靠得比较紧，而又不适合放到领域对象里面，可以将其单独做一个工具类，将其跟通用的、业务无关的工具类分开。

简单工厂类是工具类的一种，所谓简单工厂是相对于抽象工厂和工厂方法来说的，它只是根据输入值返回一个领域对象。

二.高耦合

高耦合一般表现为对其他类型的强烈依赖，一个对象发生变化会对其他对象产生剧烈的影响。我们的原则是尽量依赖于稳定的类型（或接口）。

6.原生类型依赖对象（Primitive Obsession Object）

这只狗的生日是01/02/03。
第六天，你决定在Pet对象中加入狗狗和猫咪的生日。这项工作对于你来说已经算不上什么难事了。

图 11

你把程序交给大师去看，大师输入了一串字符串，运行的结果是：这只狗的生日是01/02/03。大师问你：“这是什么意思？01年2月3日还是03年1月2日？”
你满脸冒汗，因为你已经不记得自己怎么定义的了。大师微笑着说：
不要依赖于你自己都会忘记的事情。封装之。
你回到家里，百思不得其解。“难道我值得为一个生日设计一个类吗？”

有的对象强烈依赖于语言的原生类型，比如字符串、整型数字等。正常情况下，依赖于原生类型是没有危险的，因为这些类型相当稳定，向着稳定依赖正是我们的原则。但是，如果我们同时依赖于这些原生类型的表达方式，比如字符格式、用整型表达的类型，会使得我们的系统设计变得不稳定。

我们再来看一个实际工作中的例子吧。

我们要分析两个城市之间的路径，有的同学将从城市A经城市B到达城市C的路径用“ABC”来表示，有的同学则用“A-B-C”来表示。如果对象依赖于这样的字符串，编程中就很容易出错，而且一旦表达格式发生了变化，程序还需要作出相应的修改。

一般来说，在系统中总是有一些对象要依赖于原生类型，但是我们应当尽量早地使用领域对象对原生类型做封装。比如，一开始的设计是这样的：

图 12

我们可以对route进行封装，使其不再依赖于字符串的格式。

图 13

这时候，要添加城市A只要调用Route:addCity("A")就可以了。

7.链式依赖对象（Message Chain Object）

一只狗拴一条链子就够了！
第七天，你的朋友跑过来说，他找到了那只路边捡到的小狗的主人，并告诉了你他的电话。你决定把这个电话记录在你的系统中。

图 14

你把设计交给大师去看。大师看了看类图就去翻你的代码，然后皱了皱眉头，用手指着一行代码“dog.getOwner().getAddresss();”说道：
决定一个对象好坏的是它的使用者。
你看着那行代码，若有所思的点点头。

且不说，这个代码违反了“Tell，Don't Ask”原则，就这种链式导航结构就会使得客户端与链条上的所有对象直接耦合。一旦对象之间的关系发生任何变化，都会引起客户端的变化，这违反了迪米特法则，又称最少知识原则。要解决这个问题可以在链条中找一个合适的对象添加一个函数。比如，上例中我们可以为Dog添加一个getOwnerAddress()函数。这样在客户端要取得主人的地址就只要依赖于Dog对象就可以了：dog.getOwnerAddress()。

我们要特别强调，上述解决方案只是最简单的方案之一，而且不一定是最佳方案。如果链式调用出现的次数不多甚至可以不做修改。

引申阅读：

1.《重构》中关于Message Chains的内容。

2.《程序员修炼之道》中关于迪米特法则的内容。

8.假对象（Dummy Object）

需要为邻居家的宠物单独设计一个类吗？
第八天，你的邻居看到了你设计的系统，非常感兴趣，希望你能把他们家的宠物也纳入进来。你非常高兴地答应了，因为邻居家的女主人非常热情。因为你的系统里面已经有了Owner的概念，你决定为邻居家的宠物派生一个专门的类。而且你把这个决定告诉了邻居mm，让她觉得你专门为她做了一件天大的事情。

图 15

你把新的设计交给大师去看，大师瞅了一眼，说：
多一个类就多一份牵挂。
你的脸一红，因为你不知道大师是在说设计还是说你。

系统中每增加一个类，系统的复杂性就会提高一点。每个类都是有代价的。尽管小对象往往是我们追求的目标，但是如果对象小到不仅没有专属自己的数据，也没有专属自己的行为，这样的对象还是不要的好。假对象经常出现在类的派生体系中。在倒数第二层的抽象类中已经做足了数据和方法，假对象往往只要在构造函数中填空就行了。图15正是这样的情况。

解决这种问题的一个方法是引入合适的“工厂”模式。比如，对于这个例子，我们可以将其修改为：

图 16

引申阅读：
1.《重构》一书中关于折叠继承体系、将类内联化的内容。

9.积木对象（Bricks Object）

创建一只狗到底要分多少步？
第九天，你对修改后的设计已经充满了信心。你把整个设计拿给鉴摩大师去看。鉴摩大师问到：“你怎么创建一只宠物？”
你说：“我先创建PetHead、PetBody、PetLegs和PetTail，然后把它们跟相应的生日和主人信息一起传入PetFactory的工厂方法中，就可以返回一只完整的宠物了。”
大师问：“你怎么保证别人创建宠物的时候记得这么复杂的步骤呢？”
你简直怀疑大师在故意为难你了：“难道我的PetFactory的参数列表不够清晰吗？你是说让我增加点注释吗？”
大师摇了摇头，轻轻地吐出两个字：
封装。
封装？你简直不相信自己的耳朵，难道我做了九天了，又回到了面向对象的原点？
当对象的创建可以分为多个步骤时，为了防止在步骤上出错，我们经常要对这些步骤进行封装。否则对象的创建将依赖于（耦合于）代码中未指明的步骤，这可不是闹着玩的。同样道理，如果某件事情要求对几个函数按照某个顺序进行调用，也需要对其进行封装。
封装对象创建的步骤经常采用Builder模式，当然我们也可以采用比较简单的方案，即尽量在被创建对象的内部创建自己的各个组成部分。封装对几个函数的顺序调用，为其另外提供一个函数在该函数中按照要求的顺序完成调用。图17是采用内部创建各组成部分的方式设计的对象继承结构。

图 17

引申阅读：
1.《重构与模式》中关于组合方法、链构造函数、用Creation Method替换构造函数、用Builder封装Composite的内容。
2.《设计模式：可复用软件对象的基础》种关于创建型模式的内容。
第十天，大师问你：“什么样的对象算是好对象呢？”
你说：
好的对象添一分则嫌多，减一分则嫌少。
大师笑而不语。翌日，你再去找大师，大师已经离去了。

结语

实际上，对于如何认识和理解面向对象，业界也有很多争论，其中有代表性的是斯堪的纳维亚学派（Scandinavian school）和美国学派（American School）。前者强调对真实世界中的“对象”建模——即类是由一组数据和支持这些数据的方法组成；后者强调行为封装——即类是由一组方法和支持这些方法的数据组成。前者的典型代表语言是Simula，后者的典型代表语言则是Smalltalk（我并不想较真，但是较真的读者可能会看到一些说法认为Simula是Smalltalk之母的说法，恕我不擅考究）。以GoF、Martin Fowler、Robert C. Martin等人为代表的美国学派在这场争论中占有优势。实际上，本文从某种程度上也是引导读者从斯堪的纳维亚学派向美国学派靠拢。
面向对象技术出现的目的是让编写代码更容易，然而有意思的是，对于初学者来说面向对象语言要比面向过程语言更难理解和接受。实际上，要做出好的面向对象设计需要长时间的经验积累。我在上面列出了一些相关的书籍，除了阅读之外更重要的是要在实践中摸索和体会。掌握了基本地面向对象设计的技能之后，可以继续学习有关设计模式、重构、测试驱动开发等内容，这些对于深入理解面向对象概念有很大的帮助。
在面向对象编程中，考察对象设计的好坏关键是看该对象的客户端是否能够方便地使用它；它所应用的环境中是否体现出自己的价值，特别是在环境和需求变化时是否能够比较容易地适应。这句话反过来也是成立的，即我们在设计对象的时候也应当从环境和客户端的角度去思考。这种思路往往能给我们带来额外的好处，比如容易测试、容易面向接口编程、容易实现依赖倒置。这是一个更加深入的话题，希望有机会跟大家分享和交流。

后记

当我开始写这篇文章的时候我就意识到这不是一个容易成文的话题，因为不够面向对象的情况实在是太多了，不可能用九种来概括。从某种意义上讲，Martin Fowler在《重构》一书中所列出的“坏味道”都属于不够面向对象的情况，或者至少说是“不够好的面向对象”。所以本文列出的九种情况不追求全面，更不追求正交，而是追求实用。我的目的是为刚刚接触面向对象编程的程序员——特别是从非面向对象编程转到面向对象编程的同学——提供一个容易比照的检查列表。
感谢我的同事和朋友们在本文成文过程中给予的帮助。

如果我们没有使用WCF，我们可以通过System.Runtime.Serialization.Json.DataContractJsonSerializer类(System.ServiceModel.Web.dll)或System.Web.Script.Serialization.JavaScriptSerializer类(System.Web.Extensions.dll)。

昨天在使用DataContractJsonSerializer类的时候发生件奇怪的事情，同样的代码在我机子上可以运行，在另一台机子上却运行不过。抛出不可序列化的运行时异常。提示需要在序列化的类上加定制特性Serializable，或者类上加DataContract且成员加DataMember。
在类上使用Serializable，会序列化字段，而非属性，输出的不是我想要的(一堆小写的字段，我要的是大写的公有属性)。而使用DataContract和DataMember，则必须每个要输出的属性都加上DataMember，这也比较麻烦，不是我希望的。然后同事找到了JavaScriptSerializer类，

经测试，不需要显式的添加定制特性，它会默认输出所有公有属性。OKay，这便是我想要的。

      第一个念头蹦出来，来个循环就OK了吧，但做了这么多年设计，也习惯了在思考与行动之间给自己2秒钟反思的空间，嗨，递归怎么样，是不是看起来更优雅一些，前一阵子，园子里刮起了一股优化算法的“园风”，那就考虑怎么优化吧。

      这么简单的题目，要什么优化，要什么自行车，由于本人对算法真是没的说，跟没学过一般一般，所以多次面试考试算法，我直接写，此题不会（貌似不会很有理由一样，也许是我面试不顺利的一个致命问题吧），不过这个题目我还是能够写出来的，不要笑我啊，但仔细想一想，一个面试官会问这些问题吗，为什么会问这些问题，考基础，考思路，绝对不会考人品(也许会吧)......

      带着疑问我在猜测出这道题目的初衷，对一般程序员的面试也许是考思维的严谨程度，程序的通用性、扩展性，代码的规范程度，命名是否让人看着舒服，暂不说这道题的问题：java或c语言吧，用java和C语言，咋一个应该这样出：“用你熟悉的语言编写一道程序：求1到100的累加和”，呵呵这样是否让人看了更易于发挥啊。

      还记得小学时，老师基本上会出一道这样的题目：从１加到100，看那一个小朋友用最短的时间算出来? 呵呵，数学家高斯出现了，他是那个时候算的最快的一位，噢，面试官是不是要这个结果啊！

     试想，我们只关心写程序，某年某月某日，孩子问起"从１加到100"怎么算啊，我们会不会一念没想到（可能只有我吧）高斯的思维方式，而是......也许在程序人生之外有好多我们要关注的东西，不要为了买房，买车都整天扎在程序里，年迈的时候回忆这一生，回忆到的仅仅是那个程序我写的最牛，当年牛倒了其他大牛，我开发的系统曾经风靡一时，也许对着同行你可以引以自豪，如果你到了敬老院，面对一帮搞政治，经济的，是不是就憋屈了，多关心一些生活中美好的东西，多关心政治、经济、人文，多关心自己的身体。

     算了，不在这里叨叨了，省得大家心烦，最近发现自己out了，发现自己身体每况日下，发现该提醒自己做点别的事情了，同学说去京东大溶洞，我在之前告诉他，我要搞Remoting，写完博文，我也去大溶洞去......

     创造生活，享受生活，每天都快乐、健康，这是给大家的祝愿，也是给自己的祝福。

     周末了，努力耕耘到一线的朋友放松一下吧，每天给自己半个小时的思考时间。

     By the way： 你对你的程序人生是如何规划的？

1图是单击右下角的med图标,右键出现的选项,从下往上开始数,分别是退出,停止镜像服务,重启镜像服务,锁定镜像服务,设置,工具(镜像上传和文件传送),帮助,打开med-v,图片中展示的是文件传送工具,虚拟机和主机使用该文具来传送文件,上面的是拷贝到目的地,下面的对象,注意不要选错

这个是管理条例中第一个选项卡,主要是虚拟机的名字以及全屏模式和托盘显示设置,如图第一选上后显示托盘图标,第二个是非全屏模式,但是在虚拟机中运行的程序会以红线边框标示,单击那个颜色可以自行更改,最下面那个是全屏模式,客户端启动workspace后会启动虚拟机,并在虚拟机中运行程序.为无缝体验考虑还是第一个不显示虚拟机比较好

这是第二个选项,选择要设置的虚拟机,然后第一选项中选中后客户端的设置会保存在虚拟机,可选项第一个是停止虚拟机当服务停止时,第二个可选项的意思锁定虚拟机当服务停止时

第二个大项中式设置客户端在虚拟机做了更改不会被保存.相当于还原了.下面的基本上锁定虚拟机设置等一些东西没必要更改

这里是设置客户端在虚拟机中的权限,

这里设置要在客户端发布的程序路径,第一个发布程序,下面那个大框的设置时发布整个开始菜单路径就写\即可上面的发布程序,需要注意的是要用双引号将路径框起来,否则会出错,因为众所周知的原因program files中间有空格,所以必须用双引号

这个是重定向虚拟机中的web功能

有必要使用网络的就在这里设置虚拟机的网络模式

设置虚拟机和客户端本机所占用内存,这里面是模版

image这个大选项是打包和上传以及测试用的

report是用来报告虚拟机的状态等,可以自行设定

这个选项是自动为客户端上运行的虚拟机改名,如果虚拟机有网络,但是运行到很多客户端上后,会因为都是使用的同一虚拟机而造成网络重名,所以要设置该选项,

在第一个中的虚拟机文件,如要修改虚拟机就要打开虚拟机自行修改,或者修改前面说的一些配置文件后,都要经过下面的打包和上传过程,上传后在服务器会生成vm1-日期后缀之类的,这样客户端就会下载新的更新来使用.

这个演示时在前面选择全屏模式后会出现这种运行模式,程序是在虚拟机中打开的

非全屏模式就是这样的,直接在主机打开,只是有红线标记程序而已.

1. 支持多用户，需要一个角色表（MailRole）和一个用户表（MailUser）；
2. 支持多文件夹，需要一个文件夹表（MailFolder）；
3. 支持多邮箱设置，需要一个邮箱设置表（MailConfig）；
4. 另外再加上一个邮件信息表（MailList）和一个邮件附件表（MailAttachment）。

以下附上数据库模型图：

二、程序设计分析：

1. 支持多用户，需要设计登录页面，管理员管理页面（要不然怎么管理用户呀？）用户资料页面等。
2. 支持多文件夹，需要有一个文件夹树，像163等等这些邮箱左边都有邮件夹树。
3. 支持多邮箱设置，那肯定就需要邮箱设置页面啦，再加上邮箱设置列表页面等。
4. 当然还离不开邮件管理页面。
5. 既然支持多线程收发，需要设置一个邮件收发线程类，然后我们通过 WebService 来调用。
6. 最后再整个T形框架，现在都这样就不想搞另类了。

好，这个图就免了，其他的功能若有需要，再加了。

前言

     简单易用是.Net Validator验证框架努力的目标。基于Attribute验证器标识，丰富的验证返回类型，提供可扩展的验证器接口......——又一个心愿和想法实质性的开始，开心ing  :  )

正文

      一、框架介绍

　　　　本框架基于类属性(Property)的Attribute验证器标示，匹配属性(Property)名和Form、QueryString中的Key以及服务器端控件的ID名称，再根据验证器对数据进行校验。

　　　　验证器结构图

      二、框架使用例子

　　　　2.1　　常规验证

　　　　　　2.1.1　　准备Model类User，注意引用命名空间using Lasy.Validator;

　　　　　　2.1.2　　控制台测试类

　　　　　　2.1.3　　结果显示截图

　　　　2.2　　表单验证

　　　　　　2.2.1　　User类

 　　　　　　2.2.2　　测试页面

　　　　　　　　login.aspx

 　　　　　　　  按钮代码

　　　　　　2.2.3　　效果

　　三、使用建议

　　　　3.1　　如果已经做了客户端校验，服务器端从Request中提取表单数据进行操作，可以直接使用Validator(Type type, bool checkAll, bool setDefaultValue)构造函数，然后从ValuesResult中取得已经校验完毕IDictionary<string, object>数据。

　　　　3.2　　NoValidator与ValuesResult在提取表单数据时配套使用。

　　　　3.3　　调试的时候注意类的Attribute是静态缓存的，需要清理或重新生成修改后的验证器标识才管用！

　　四、下载

　　　　4.1　　源代码　　Src

　　　　4.2　　文   档　　Lasy.Validator.chm

结束语

      虽然造轮子常常是一件吃力不讨好的事情，但是怀着我觉得好用，或者想做一个好用的东东出来，推荐给朋友试试看的心情就会好很多，何况还是有许多热心人提供宝贵的建议:  )

QQ抢车位外挂--小研究成果展示
首先，我想在这里说明一下，在这里，我希望大家能通过我写的文章，学到一些外挂开发思路性的东西，至于，怎么通过JS加密腾讯要求的密码，这些细节的东西，大家可以下来去研究。
我今天针对上次的文章，主要针对

登陆后怎么获取自己的信息，好友的信息，以及如何贴条

我看了大家对我上篇文章的评论，有些同志有比我发出来的抓包工具更好的抓包工具，大家可以根据需要，用自己习惯的，这里我还是用上次我提供下载地址的 HTTPAnalyzer  工具

好了，进入正题，上篇文章我已经讲了如何正确登陆QQ空间。
登陆之后，会有一个返回结果，

结果字符串中间会包括一个字符串

g_iLoginUin=XX的QQ号

如下图：

。。。。。。。。。。。

OK，现在登陆成功了
我提供给大家一个类   关于Post提交或者Get操作的类
用这个类，大家可以 保存当前的Cookie
这样，在下次像提交请求时，服务器就会认定为，你是登陆状态了，呵呵
类如下：

HttpHelper.cs 

在使用这个类时，要注意保存自己的Cookie

Code
1//切忌这个 _cookieContainer一定要是全局的，因为如果登录成功，这个_cookieContainer保存了你的登录状态
2//并且腾讯对你登陆状态保留时间是有限的，一般1小时如操作就视为就会登陆超时
3CookieContainer _cookieContainer = new CookieContainer();
4//new出来一个http请求对象
5HttpHelper _help = new HttpHelper(_cookieContainer);
6//模拟执行一个Get操作，过执行Post操作，请自行参阅GetHtml的方法重载
7string responseStr = _help.GetHtml("你请求的URL", _cookieContainer);

 好了，现在我们来获取我们自己的车辆信息，哈哈，比较兴奋啊，成功越来越近了

我们还是用HTTPAnalyzer 工具进行抓包

我们首先先拿IE进入自己的空间-》抢车位之后，点击下抢车位上的

  上的  按钮

哇塞，大家看到了吗？ 我们的抓包工具在第12行抓到了我们想要的数据啊

里边有我们所有车的数据， 停在什么位置上，车的价钱，以及停车多少分钟，等等信息，稍作分析便可以使用腾讯的xml数据了

要注意的是这是一个Post操作，Post地址是

http://world.show.qq.com/cgi-bin/parker_user_info?uin=

好了，已经获取我们的QQ抢车位所有的车辆信息了

我们再来测试下停车功能吧，先找个车试试 吼吼~~

首先我们找到一个好友，进入他的停车场，然后找个空位置，选择一个我们的车，点击停车

点击确定，我们看看是否能再次抓到有用的数据呢？？

我们看到，Post之后，居然又返回一个xml文件，腾讯对数据的返回大部分是xml文件

返回一个 此车停在XX好友车位上的标示（opuin)

以及  carid(车的自编号);money(赚取的钱)等等..

我们来看看这个Post提交  究竟提交了些什么数据呢

我们不难发现，和上边返回的xml差不多 opuin就是当前你选择停车的好友QQ号

carid是车编号，parkno是你好友的停车位编号，当前我们是停在了2号车位 呵呵

这个停车就基本分析完了，大家按照这个思路就完全可以写自己的停车程序了

这几天真的很忙，很抱歉没及时跟进文章，我的抢车位外挂应该在下周周二出一个新的版本

目前还在测试，就不给大家放出来新版了（别大家运行看到很多bug就不好咯）

好了，我先分析到这里，明天还得上班，休息了，晚安

本文地址: 发一个基于jQuery的多标签浏览插件

本文作者：QLeelulu

转载请标明出处，首发于博客园！

注：该插件提取于动易CMS系统管理后台。

该插件适用于使用框架页的管理系统后台。

该插件只能应用于同域的URL，跨域的URL由于Javascript的安全限制，会出错。

不说废话，先看Demo，点击下面的链接将在下面的iFrame中打开（指定了target="main_right"）：

jQuery Ajax 全解析     ASP.NET MVC 入门系列教程
博客园(在新标签中打开)

下面是代码，有注释，就不多说了。

/*  
*
* 该插件只能应用于同域的URL，跨域的URL由于Javascript的安全限制，会出错。
*
* 新建一个标签：PE_FrameTab.AddNew(url)
; 如果url为空则是新开一个空白的标签页。
* 关闭当前标签：PE_FrameTab.CloseCurrentTab()
* 从当前标签切换到其他标签时触发：BeforeSwitch(); 如果该函数存在并返回false则不切换标签.该函数直接写在当前页面中.
* 从其他标签切换到当前标签时触发：SwitchInto(); 如果该函数存在则执行.该函数直接写在要切换到的页面.
* 在关闭当前标签页的时候触发：OnCloseTab(); 如果该函数存在存在则执行.该函数直接写在当前页面中.
*/
var lastFrameTabId = 1; //最后新建的FrameTabId，用于新建FrameTab
var currentFrameTabId = 1; //当前显示的FrameTab
var frameTabCount = 1;
var StyleSheetPath ="";

var PE_FrameTab = {
    //新建一个标签
    AddNew: function(url) {
        AddNewFrameTab(url);
    },
    //关闭当前标签
    CloseCurrentTab: function(){
        jQuery("#iFrameTab" + currentFrameTabId).find(".closeTab").click();
   }
};

///给tab标签注册切换和关闭tab事件
jQuery.fn.iFrameTab = function() {
    jQuery(this).each(function() {
        var cr = jQuery(this);
        var tabId = cr.attr("id").replace("iFrameTab", "");
        cr.click(function() {//切换FrameTab
            SwitchIframe(this);
        }).find(".closeTab").click(function() {//关闭FrameTab
            if (frameTabCount > 1) {
                var mainRightFrame = jQuery("#main_right_frame iframe[tabid='" + tabId + "']");
                var bClose = mainRightFrame[0].contentWindow.OnCloseTab ? mainRightFrame[0].contentWindow.OnCloseTab() : true;
                if (bClose) {
                    if (cr.attr("class") == "current") {//如果关闭的标签是当前标签，则切换到前一标签，如果前一标签不存在，则切换到后一标签
                        var nextIframe = cr.prev("li[id^='iFrameTab']");
                        if (nextIframe.length <= 0) { nextIframe = cr.next("li[id^='iFrameTab']"); }
                        SwitchIframe(nextIframe[0]);
                    }
                    //清理
                    cr.remove();
                    jQuery("#frmTitle iframe[tabid='" + tabId + "']").remove();
                    mainRightFrame.remove();
                    frameTabCount--;
                    CheckFramesScroll();
                }
            }
        }).end().dblclick(function() {
            jQuery(this).find(".closeTab").click();
        });
    });
    return jQuery(this);
}


///切换tab
function SwitchIframe(iFrameTab) {
    var tabId = jQuery(iFrameTab).attr("id").replace("iFrameTab", "");  //鼠标点击的tab的id
    if (currentFrameTabId == tabId) { return false; }
    //判断是否允许切换Tab
    var switchFunc = jQuery("#main_right")[0].contentWindow.window.BeforeSwitch;
    var bSwitch = (switchFunc) ? switchFunc() : true;
    if (!bSwitch) { return false; }

    var currentGuideSrc = jQuery("#frmTitle iframe[tabid='" + currentFrameTabId + "']").attr("src");
    SetCurrentFrameTab(iFrameTab);

    var mainFrames = jQuery("#main_right_frame > iframe").hide().attr({ "id": "", "name": "" });
    var newMainFrame = jQuery("#main_right_frame iframe[tabid='" + tabId + "']");
    //将iframe的window.name设为空，使<a target="main_right" />只对当前iframe有效
    mainFrames.each(function() { this.contentWindow.window.name = ""; }); 
    
    if (newMainFrame.length <= 0) {//是否新建标签
        newMainFrame = jQuery("#main_right_frame").prepend(jQuery("#iframeMainTemplate").html())
                .find("[tabid=0]").attr({ "tabid": tabId, "src": "about:blank", "id": "main_right", "name": "main_right" })
                .css("display", "block");
    } else {
        newMainFrame = jQuery("#main_right_frame iframe[tabid='" + tabId + "']")
            .attr("id", "main_right").attr("name", "main_right").show();
    }
    //指定iframe的window.name，使<a target="main_right" />有效
    newMainFrame[0].contentWindow.window.name = "main_right";
    frames["main_right"] = newMainFrame[0].contentWindow.window;

    currentFrameTabId = tabId;

    var switchInto = jQuery("#main_right")[0].contentWindow.window.SwitchInto;
    if(switchInto){ switchInto(); }
}

///初始化新建标签按钮
function InitNewFrameTab() {
    jQuery("#newFrameTab").click(function(url) {
        AddNewFrameTab(url);
    });
}

function AddNewFrameTab(url){
    //jQuery("#FrameTabs .current").removeClass("current");
    var btn=jQuery("#newFrameTab");
    jQuery('<li id="iFrameTab' + (++lastFrameTabId) + '" ><a href="javascript:"><span id="frameTabTitle">(无标题)</span><a class="closeTab"><img border="0" src="' + StyleSheetPath + 'images/tab-close.gif"/></a></a></li>')
            .insertBefore(btn).iFrameTab();
      frameTabCount++;
      SwitchIframe(jQuery("#iFrameTab" + lastFrameTabId)[0]);
       jQuery("#main_right").attr("src",url);
      if (CheckFramesScroll()) { jQuery("#FrameTabs ul:eq(0)").css("margin-left", cW - fW - 40); }
}

function SetCurrentFrameTab(selector) {
    jQuery("#FrameTabs .current").removeClass("current");
    jQuery(selector).addClass("current");
}
///检查是否需要滚动
function CheckFramesScroll() {
    var ft = jQuery("#FrameTabs");
    window.cW = ft.width(); //包含Tabs的容器宽度
    window.fW = ft.find("ul:eq(0)").width();
    ft.unbind("DOMMouseScroll").unbind("mousewheel");
    if (fW > cW) {
        if (jQuery.browser.mozilla) {
            ft.bind("DOMMouseScroll", function(e) {
                ScrollFrames(cW, fW, e);
            });
        } else {
            ft.bind("mousewheel", function(e) {
                ScrollFrames(cW, fW, e);
            });
        }
        jQuery("#FrameTabs .tab-strip-wrap").addClass("tab-strip-margin");
        jQuery("#FrameTabs .tab-right, #FrameTabs .tab-left").css("display", "block");
        return true;
    } else {
        jQuery("#FrameTabs ul:eq(0)").css("margin-left", 0);
        jQuery("#FrameTabs .tab-right, #FrameTabs .tab-left").css("display", "none");
        jQuery("#FrameTabs .tab-strip-wrap").removeClass("tab-strip-margin");
        return false;
    }
}
///Tab滚动。
///cW为包含Tabs的容器宽度；fW为全部Tabs的宽度；y为指定的位移，如果不指定y，则使用event中的位移。
function ScrollFrames(cW, fW, event, y) {
    if (!y) {
        if (event.wheelDelta) {
            y = event.wheelDelta / 5;
        } else if (event.detail) {
            y = -event.detail * 8;
        }
    }
    var jList = jQuery("#FrameTabs ul:eq(0)");
    var ml = jList.css("margin-left");
    ml = Number(ml.toLowerCase().replace("px", ""));
    if ((ml < 0 && y > 0) || (ml - cW > -fW - 40) && y < 0) {
        ml = ml + y;
        if (ml >= 0) { ml = 0; }
        if (ml - cW <= -fW - 40) { ml = cW - fW - 40;}
        jList.css("margin-left", ml);
    }
}
//注册Tab超出范围时左移、右移事件
function RegScrollFramesBtn() {
    jQuery("#FrameTabs .tab-right").click(function() { 
        ScrollFrames(window.cW,window.fW,null,-50);
    });
    jQuery("#FrameTabs .tab-left").click(function() { 
        ScrollFrames(window.cW,window.fW,null,50);
    });
}

//设置标签的标题
//tarFrame参数为目标iframe
function SetTabTitle(tarFrame) {
    var title = "";
    try { title = tarFrame.contentWindow.document.title; } catch (e) { }
    var subTitle = title = title || "(无标题)";
    if (title.length > 6) { subTitle = title.substr(0, 5) + ".." }
    jQuery("#iFrameTab" + jQuery(tarFrame).attr("tabid")).find("#frameTabTitle").html(subTitle).attr("title", title);
}

//初始化
jQuery(function() {
    jQuery("#FrameTabs li[id^='iFrameTab']").iFrameTab();
    InitNewFrameTab(); //初始化新建标签页按钮
    RegScrollFramesBtn();
});

Enjoy!! By Q.Lee.lulu。

最后给出代码打包下载：FrameTab.rar

1. 尽量使用代码控制；
2. 尽可能早的计划好所有的用户控件；这样可以提前预期控件之间相互运作情况，便于整合项目；
3. 尝试分割不同功能到不同的用户控件； 现在无论国内国外，开发队伍通常来说都是3个人以上，分割不同功能到不同的用户控件，可以减少相互之间的冲突和影响； 另外，在测试的时候发现问题，对于不同的小功能区域，方便Bug定位；另外也方便功能模块的再利用。 这个是现在Web项目开发的一个常用规则。
4. 尽量少用Loaded事件；
   
5. 初始化的问题； 在每个用户控件中，需要创建Initialize和Deinitialize公共方法。  在实际项目中，你可以把Event Handlers或者必须要运行一次的代码，添加到Initialize方法中； 另外，也可以不用添加新的构造函数，直接传递参数到Initialize方法，通过New MyUserControl()使用这些参数； 最后，你可以使用Deinitialize方法清空控件，如果你调用了需要自定义的控件，使用Deinitialize方法是非常必要的；
6. 不要在XAML添加Event Handles； 因为XAML是属于前台设计人员，而Event Handling属于开发人员，所以，Event Handler非常容易使用代码进行添加；另外一个原因，如果你使用代码添加了一个Event Handler，当该事件的控件名称改变或者该控件被删除，编译器会提出错误说明； 但是如果把Event Handler放在XMAL，当该事件的控件名称改变或者该控件被删除，项目将返回一个常规异常，没有详细错误信息提示；
7. 认真设计项目布局； 我项目起步时，浪费了许多时间，在项目布局上，如果，布局合理，一定能节省很多开发时间；这样就需要开发人员对Grid，StackPanel，Canvas，Border，Popup，ScrollViewer，DockPanel等布局控件有深刻的了解；通常，你会发现，Grid非常适合做Header，Footer，Sidebar等等； 而复杂的布局结构，建议使用Canvas，需要注意的是，如果Canvas的高和宽是固定的，这样就很容易造成布局混乱，这点一定要注意；如果需要调整子控件的布局，推荐使用StackPanel；设计Silverlight项目布局，通常我们习惯使用Expression Blend，但是，强烈建议你，在使用Blend后，需要在VS下对XAML代码进行一次核查，这样可以确认各个控件的参数正确，同时也可以删除Blend自动产生的多余代码；
8. 尽量避免使用固定的高度值和宽度值；在不设置固定的高度和宽度时候，Silverlight会根据你的解析度自适应浏览器界面，同时，各个控件将会自动缩放，以及排列位置； 另外，尽量不要使用负值的Margin，防止样式变形；
9. 不要将机密信息放在代码中； 众所周知，Silverlight是一个客户端技术；用户在使用的同时，将会下载XAP文件到本地，这样非常容易被反编译； 所以，一定不要把敏感的机密数据放在代码中；
10. 不要使用Image作为按钮控件； 在Silverlight1.1中没有Button控件，所以我们使用Image作为按钮； 但是在Silverlight2或者3中，已经提供了Button控件，我们需要尽量使用Button控件； 这个原则也适合其他控件，尽量使用Silverlight提供的控件，方便状态管理和事件管理；
    
11. 在项目性能上，尽量减少XAP的尺寸，提高加载项目速度，另外，减少各个用户控件的载入时间； 避免使用Windowless=True; 
12. 使用Web Service进行服务器数据存取； 因为Silverlight是运行在用户主机的，所以不能直接和服务器或者数据库进行通讯，当前有很多种方式可以存取服务器信息和数据库，但是推荐使用Web Service（WCF），个人认为这个方法是最简单，最快捷的；
13. 小心使用Isolated Storage; 一定不要把机密信息放在Isolated Storage;

解决办法：

1、如果在 Windows Vista Service Pack 1 或 Windows Server 2008 上同时使用 Real Networks RealPlayer 11 和 Internet Explorer 8，会出现已知的程序兼容性问题。若要解决此问题，请安装修补程序 957055。安装 Internet Explorer 8 时，系统将自动接收此更新。

有关详细信息，请参阅 Microsoft 知识库中的以下文章：http://support.microsoft.com/kb/957055/   Vista SP2包含该更新包，但还是会有问题，建议删除IE8,恢复到IE7就正常了。我就是使用这个OK。如何删除IE8请查看如何删除IE8

2、要同时安装Internet Explorer 8 和RealPlayer 11 ，必须先安装RealPlayer 11 ，才能安装Internet Explorer 8 。

3、如果安装Internet Explorer 8 后再安装RealPlayer 11 ，可能会遇到某些程序兼容性问题。要解决这些问题，请卸载Internet Explorer 8 ，然后再将它重新安装。

另：

rm播放控件的详细的API接口说明：（非常的全面）但目前还没有找到mediaplayer的详细API，唉！遗憾……

http://service.real.com/help/library/guides/extend/embed.htm

这样当你访问c:\wwwroot\webapp\temp或进行读写的时候，直接反映到c:\temp目录中，而且因为系统监视程序监视的实际物理路径而不是映射路径所以不会引起ASP.NET应用程序重新启动。

这样就可以解决在VS宿主下的调试问题。

l         首先，如果你需要压缩静态文件（HTML），需要在硬盘上建一个目录，并给它“IUSR_机器名”这个用户的写权限。如果压缩动态文件 （PHP，asp，aspx）就不需要了，因为它的页面是每次都动态生成的，压缩完就放弃。

l         添加Gzip的Web服务扩展并设置为有效

l         设置网站压缩有效

  进入“服务”标签，选上启用动态内容压缩，静态内容压缩。

   此时重启IIS，压缩就生效了。但是默认设置压缩的文件格式太少，可以进一步设置。

l         修改 MetaBase.xml，建议先备份。

  可以用记事本打开，找到 IIsCompressionScheme，有三个相同名字的段，分别是deflate,gzip,Parameters，第三段不用管它，前两段有基本 相同的参数

 HcDynamicCompressionLevel ，设置压缩率，取值0~10，0不压缩，10最高压缩率，这里设置成9，9是性价比最高的一个。

  HcFileExtensions，需要压缩的静态文件扩展名，默认只有htm，html，txt，可以把js，css添加进去。建议按原来的格式，用换行作为分隔。    HcScriptFileExtensions，需要压缩的动态文件扩展名，这里添加aspx。

  Location ="/LM/W3SVC/Filters/Compression/deflate"设置如图：

   Location ="/LM/W3SVC/Filters/Compression/gzip"设置如图：

l         iisreset -stop 停止IIS，保存MetaBase.xml

l         iisreset -start 启动IIS

  ok,that's over,上传图片太累了，本文为原创，如转载，请注明原处！