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

需要指出两点：

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,上传图片太累了，本文为原创，如转载，请注明原处！

还是先上一段测试代码：

比较简单，就是在不同的时候打印几个字符串。

我看了看IL，在Foo 的代码里发现了一个特殊的指令，用ILDASM dump出IL：

leave.s IL_0028,这个指令是什么意思呢？查了查msdn：

看了看，也不是很明白，到底是怎么执行呢？我想到了一个Tool，sharpdevelop，一个开源的IDE，记得好像能调式IL，

下了一个安装，安下断点，调式发现leave.s实际上执行finally里的代码，然后再到IL_0028；我试着将IL_0028改为

IL_0029，结果同样执行完finally之后则跳到了IL_0029.

将IL_0028改为IL_000d，则没有执行finally里的代码，在IL_000d和IL_0018之间形成了死循环，不停的打印字符串“enter Foo try”。

将IL_0028改为IL_0030，则报错。

这时候大家可能就明白了，leave.s target其实就是执行其后的finally代码块然后跳到target处。

能保证finally一定执行的秘诀就在LEAVE指令。

在这里再补充一点吧。免得大家看了没什么收获，其实方法都告诉大家了，可以自己去尝试啊，自己动手才能记得牢啊。

代码改为：

大家能看出打印结果是什么吗？（leave写错了，大家请忽略）

看到了leave语句一个没有执行，但是嵌套的finally都执行了，这是为什么呢？

看Foo的IL：

在try1里引发了异常，其实有没有catch都一样，经IL的 leave.s指令执行finally，但是可以看到，不仅执行里面的finally1，而且连外面的finally也执行了。

我在<<CLR via C#>>里看到这方面的内容，原意大概是：

这样看来其实可以理解：leave指令会执行其后有层次关系finally，然后跳至函数的末尾，这点MSDN说的很含糊。

.Net开发

移动应用开发

数据库技术

安防监控/多媒体/流媒体专题开发

视频监控相关文章

流媒体与视频监控开发相关博客文章系列收集

实际上，即使通过ClientBase<T>对象进行服务调用，其内部也是调用ChannelFactory<T>创建的服务代理。整个ChannelFactory<T>的创建是一项相对复杂并且费时的工作，会涉及很多诸如反射、配置文件的读取等操作。为了提高服务调用的性能，在.NET 3.5中，WCF在ClientBase<T>中引入了ChannelFactory<T>的缓存机制。

一、如何实现对ChannelFactory<T>的缓存

为了让读者对ChannelFactory<T>的缓存机制有一个直观的认识，我们来做一个简单的实验：在一个Console应用中执行如下的代码，其中CalculatorClient可以看成是本节开篇时自定义的服务代理类。在本例中，先后以相同的方式（调用相同的构造函数，传入相同的参数）创建并开启了两个CalculatorClient对象，然后检验它们的ChannelFactory是否是相同的对象。

CalculatorClient proxy1 = new CalculatorClient("calculateservice");
proxy1.Open();
CalculatorClient proxy2 = new CalculatorClient("calculateservice");
proxy2.Open();
Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}", 

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));

输出结果：

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = True

从输出的结果，可以看出两个不同的ClientBase<T>对象使用了相同的ChannelFactory<T>对象。这得益于在.NET 3.5中新加入的ChannelFactory<T>的缓存机制。那么，在WCF客户端框架内部对ChannelFactory<T>的缓存是如何实现的呢？

实际上，ChannelFactory<T>的缓存实现很简单，被创建出来的ChannelFactory<T>集合通过ClientBase<T>的一个静态变量保存起来。我们可以将这个ChannelFactory<T>集合看成是一个字典，字典的值就是ChannelFactory<T>，而键则通过下面三个对象派生：

• CallbackInstance：以InstanceContext对象表示的对回调对象的封装；
• EndpointConfigurationName：终结点在配制文件中的名称；
• RemoteAddress：终结点的远程地址，类型为EndpointAddress。

它们分别与ClienBase<T>构造函数中相应的参数相匹配。当调用某个构造函数创建对象的时候，WCF将传入的三个参数作为Key（如果再构造函数中并未指定相应的参数，会使用默认值，EndpointConfigurationName、CallbackInstance和RemoteAddress的默认值分别为*、null和null），从缓存（静态变量）中去找匹配的ChannelFactory<T>对象，如果成功找到，则直接返回，否则重新创建，在返回之前将其放入缓存中。

从这个意义上讲，多个ClienBase<T>对象能够重用相同的ChannelFactory<T>对象的前提是它们使用相同的构造函数，并传入相同的参数被创建。为了验证这一点，再来做一个实验，只须要将上面的例子稍加修改，通过另一个重载构造函数来创建CalculatorClient对象。

CalculatorClient proxy1 = new CalculatorClient("calculateservice"，new EndpointAddress("http://127.0.0.1:9999/calculateservice");
proxy1.Open();

CalculatorClient proxy2 = new CalculatorClient("calculateservice");
proxy2.Open();
Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}", 

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));

输出结果：

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = False

实际上，proxy1和proxy2最终使用的终结点地址是相同的（http://127.0.0.1:9999/ calculatorservice），只不过一个是通过代码指定的，另一个则是通过配置文件配置的。但是，就是因为创建ClienBase<T>时使用了不同的构造函数重载，导致不能重用同一个ChannelFactory<T>对象。

ChannelFactory<T>的重用避免了频繁地常见ChannelFactory<T>对象，从而获得更好的性能。在具体的应用中，我们应该尽可能地利用这样的机制。但是，由于编程人员对ChannelFactory<T>的缓存机制不了解，不知不觉就会使这个缓存机制失效。接下来就来讨论这个问题。

二、ChannelFactory<T>缓存机制的失效

总体来讲，下面的两种情况会引起ChannelFactory<T>缓存机制失效。

• 在构造函数中传入绑定对象构建ClientBase<T>；
• 在ClientBase<T>开启（调用Open方法）之前，访问如下三个只读属性：ChannelFactory、Endpoint和ClientCredential。

为了加深读者的理解，我们通过实验的方式来证实上面的两种说法。为了验证在构造函数中传入绑定对象对ChannelFactory<T>缓存机制的影响，写了如下的代码：通过Binding和EndpointAddress对象创建ClienBase<T>对象。

Binding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress("http://127.0.0.1:9999/calculateservice");
CalculatorClient proxy1 = new CalculatorClient(binding,address);
proxy1.Open();
CalculatorClient proxy2 = new CalculatorClient(binding, address);
proxy2.Open();
Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}", 

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));

输出结果：

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = False

接下来，再通过实验整个在ClientBase<T>开启（调用Open方法）之前访问ChannelFactory、Endpoint和ClientCredential三个只读属性对ChannelFactory<T>缓存机制的影响。在这里，以访问ChannelFactory属性为例

CalculatorClient proxy1 = new CalculatorClient("calculateservice");
ChannelFactory<ICalculator> factory = proxy1.ChannelFactory;
proxy1.Open();
CalculatorClient proxy2 = new CalculatorClient("calculateservice");
proxy2.Open();
Console.WriteLine("object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = {0}", 

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory));

输出结果：

object.ReferenceEquals(proxy1.ChannelFactory, proxy2.ChannelFactory) = False

在上面的例子中，在Proxy1的Open方法调用之前，调用了只读属性ChannelFactory，并将其赋值到一个临时变量中，中间根本没有对ChannelFactory<T>作任何修改，仅仅一次我们认为微不足道的对只读属性的访问就破坏了WCF客户端框架对ChannelFactory<T>的缓存机制。

三、如何有效利用ChannelFactory<T>的缓存机制

为了能够充分利用ChannelFactory<T>的缓存机制，获得更好的服务调用性能，我们可以得出以下两个最佳实践：

• 避免通过人为指定绑定对象创建ClientBase<T>对象，应该尽可能使用配置的绑定信息；
• 避免在ClientBase<T>开启之前读取ChannelFactory、Endpoint和ClientCredential三个属性，或者在创建ClientBase<T>之后显式调用Open方法开启ClientBase<T>对象。

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