一.Html安全隐患

1.CSRF攻击【漏洞】

      之前外我写过一篇《浅谈CSRF攻击方式》，如果想详细了解CSRF原理及其防御之术，可以看一下。

      这里简单距个例子说明一下：

存在CSRF漏洞Html代码：

<form action="Transfer.php" method="POST">
　　　　<p>ToBankId: <input type="text" name="toBankId" /></p>
　　　　<p>Money: <input type="text" name="money" /></p>
　　　　<p><input type="submit" value="Transfer" /></p>
</form>

以上漏洞的攻击代码：

<form method="POST" action="http://www.Bank.com/Transfer.php">
<input type="hidden" name="toBankId" value="hyddd">
<input type="hidden" name="money" value="10000">
</form>
<script>
document.usr_form.submit();
</script>

      如果用户在登陆www.Bank.com后，访问带有以上攻击代码的页面，该用户会在好不之情的情况下，给hyddd转账10000块。这就是CSRF攻击。

2.包含不同域的Js脚本【隐患】

      在Html页面中，包含如：

<script src="http://www.hyddd.com/hello.js"/>

不同域的脚本文件，是一种值得慎重考虑的行为，因为你把本站点的安全和其他站点的安全绑定在一起了。黑客可以通过入侵修改www.hyddd.com的hello.js文件，达到攻击的效果。比如说：JavaScript Hijacking（关于JavaScript Hijacking可以参考《深入理解JavaScript Hijacking原理》）。

3.Html中的Hidden Field【隐患】

      注意对隐藏字段的使用。比如hidden的<input>标签。

      不要把敏感的信息存放在隐藏字段中，以防被别人更改替换和浏览器缓存。

4.上传文件【隐患】

      请慎重对待上传文件这一功能，因为攻击者有可能借这个机会执行恶意代码，如图：

所以请小心处理上传文件功能。

      以上是我搜集到的4种关于Htm的安全隐患，资料的主要来源都是Fortify的一些文章 ，如果有错漏或者补充，请和我联系:>

转载请说明出处，谢谢![hyddd(http://www.cnblogs.com/hyddd/)]

二.参考资料

1.《Input Validation and Representation Fortify Software》

2.《Common Weakness Enumeration》

3.《浅谈CSRF攻击方式》，作者：hyddd

有人说，不好回答，傻呀你，不就是因为她简单吗？

接上篇，说说简单工厂模式。

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

先送上图例：

闪电晚上在维吾尔族餐馆吃了顿炒面片，顺便呢，点了盘花生和毛豆的拼盘。

回来之后呢，就有了以上的UML图和以下闪电写的代码了。

俺们县啊，可是个农业大县，但是又出不了优质主粮，农民呢，就想办法种些农副产品，一来自己可以改善一下伙食，二来呢，如果产量好的话，也能出售个好价钱。

农民甲有一些沃土地，他觉得种花生豆将来会高产。

农民乙呢，有一些普通的土地，他觉得啊，种毛豆应该不会亏本。

于是乎……

客户机程序：

　　不久前有朋友写了一篇题为《提供生成静态页核心代码》的文章，介绍了一种“向硬盘写入页面文件”的方式。这篇文章的内容在此并不多作讨论，这里引用一下作者给出的摘要：

网页生成静态Html文件有许多好处，比如生成html网页有利于被搜索引擎收录，不仅被收录的快还收录的全。前台脱离了数据访问，减轻对数据库访问的压力，加快网页打开速度。

　　这种说法存在一个严重的问题，因为它混淆了两个概念：“静态页”有利于网站性能，和“静态页”有利于SEO。有朋友可能会说：“这两点说的都没有错啊，不信你去搜索引擎上查一下，都有很多资料”。是的，这两种说法都能在搜索引擎上找出“依据”来，只可惜在这种两种情况下的“静态页”所指的内容，或者说是“做法”完全不同，可以说没有任何关系。换句话说，这里造成“混淆”的原因是“指代不明”。为了方便阐述，在本文接下来的部分中将尽可能避免“静态页”，“静态化”等词语，而是使用以下两种区分明显的说法进行阐述：

• 规范页面URL
• 缓存页面内容

规范页面URL

　　如今在开发的Web应用程序时，往往需要从客户端获取一些信息，然后根据这些信息生成页面。例如，我们需要从客户端获取一个“页码”，然后在页面上呈现出这一页的内容。从客户端传递信息的方式有多种，其中最常见的便是通过Query String进行传递。例如，我们可以通过Article.aspx?id=3这样的方式来请求id为3的文章。不过如果纯粹使用Query String来传递信息的话，一个URL可能会带有许多项Query String。例如ArticleList.aspx?page=3&keywords=helloworld&category=6&....。

　　有种说法是，这样的URL由于明显是动态的，因此搜索引擎对它的处理会有所负面倾斜，例如将其权值放低。因此，很多程序都会把为URL规范为特别的形式，例如Article/3，甚至是Article_3.html。使用htm或html作为URL的结尾，是为了“欺骗”搜索引擎，让搜索引擎以为这是一个直接从存储设备上直接读取的资源，它不会改变，因此“它的权值会相对提高”。实际上老赵并不同意这个说法，而且似乎也没有实际案例可以证明这一点——当然我也无法证否，因此无法判断这个说法的正确性。不过这篇文章并不是在追究这个问题，在这里我们暂且认为它有道理吧。

　　要实现这点，我们所要实现的是进行URL重写。URL重写的目的，是在服务器端把客户端请求的URL（如Article_3.html）当作另一个请求进行处理（如Article.aspx?id=3）。请注意，这个工作是在服务器端完成的：

　　对于搜索引擎的爬虫来说，它根本意识不到这个URL是在直接读取资源，还是经过了动态的请求。我们是Web应用程序的编写者，对于一个请求我们可以使用我们任意的方式进行处理，想欺骗搜索引擎还不是易如反掌？不过这种做法对于网站性能来说是否有帮助？没有，肯定没有。

　　这种改变URL，想要获取更好SEO效果的做法，有些人也会把它叫做“伪静态化”。老赵不知道这种说法合不合适，我是从来不会使用这样的说法的。

缓存页面内容

　　动态生成一个页面的开销往往很大，例如需要多次查询数据库或者外部服务。为了减少服务器端的开销，为了加快网站的运行效率，有时候在服务器端会将一个页面的整体内容保存为一个文件，这样每次在服务器端获取客户端请求的时候，只要读取相应的文件即可，而不需要重新查询数据库或外部服务并重新生成页面内容：

　　同样的，这些事情完全是在服务器端进行的处理，搜索引擎的爬虫对此一无所知。即使搜索引擎认为Article.aspx?id=3这样的请求是由服务器端即时生成的（当然搜索引擎真不会考虑这些），我们编写的服务器端逻辑同样可以直接读取磁盘上的文件，并且直接输出。这种做法自然是为了效率，不过……

　　这种做法和SEO有没有关系？没有任何关系，因为爬虫根本不知道我们做了这些。

　　这种做法是否需要在硬盘上生成一个html文件？没有必要，我可以生成txt文件，可以生成jeffz文件，甚至我可以不生成文件，而是将页面内容直接存放在内存中，甚至是高性能的Key/Value Store里。

　　这种做法是否需要把URL修改为html结尾？没有必要，URL改不改都无所谓，改成什么也都无所谓。

总结

　　有时候事情其实就是那么简单，但是还是会让人混淆。一句话听上去很正确，但是一旦“指代不明”，正确的话也变成错误的了。例如本文一开始引用的文章，它是为了“缓存页面内容”而使用的做法，这个做法和SEO没有任何关系，因此说“生成html网页有利于被搜索引擎收录，不仅被收录的快还收录的全”是将其目的与“规范页面URL”混淆了起来。错误产生在这里。在那片文章后面的评论中，有朋友回复说目前的搜索引擎已经不关心URL是否是html还是别的什么形式了。这种说法可能也是正确的，不过并没有谈在点子上。因为无论搜索引擎如何处理HTML，文章的内容都和搜索引擎没有一丝一缕关系。

　　因此，如果您以后要谈“静态页”或网页“静态化”的时候，请区分您究竟是在谈“规范页面URL”还是“缓存页面内容”。

　　如果您说“静态页有助于SEO”，明白人知道您是再指“规范页面URL”，而某些朋友可能就会认为您是指在服务器端缓存页面内容。

　　如果您说“静态页有助于提高网站性能”，明白人知道您是指“缓存页面内容”，而某些朋友可能就会认为您是指使用“URL重写”来规范URL样式。

　　如果您说“静态页，既有助于SEO，又有助于提高网站性能”，那么（我希望）明白人就会带您来看现在这篇文章，而某些朋友可能就会……哎哎。

SSIS 包有三种部署方式：文件部署，SQL Server 目录和数据库。 

• 文件部署方式

Code
using DTS = Microsoft.SqlServer.Dts.Runtime;
using System.Collections;
using System.Collection.Generic;

DTS.Package dtsPackage = null;
DTS.Application dtsApplication = null;

dtsApplication = new DTS.Application();
//指定文件路径加载 package 
dtsPackage = dtsApplication.LoadPackage(@"c:\Package.dtsx", null);
DTS.Variables packageVariables1 = dtsPackage.Variables;
packageVariables1["FirstVar"].Value = "12345321"; //传递参数 
packageVariables1["SecondVar"].Value = "2312";

DTS.DTSExecResult packageResult = dtsPackage.Execute();

• SQL Server 目录

• 数据库：关于数据库的方式，目前实际没有应用过，今后如果测试成功后再补充完整。

      今天说说单例模式。

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

      先送上图例。

      闪电经常去公司底楼餐厅吃饭，发现一个问题，餐厅四周有很多玻璃门，可奇怪的是呢，所有的门都封上了，只留了一个门供大家出入。

      闪电小的时候也玩那种玩具枪，后盖抠开，一颗一颗地子弹上膛，食指使劲，然后“啪”的一声，一颗子弹就飞出去了！

      闪电吃过一种筒状的糖，开开盖口，每次只能倒出一颗，入口即化，呗儿甜！

      这些难道不是单例模式的应用场景吗？单例维持实例化的秩序是好样的，让类的实例能有计划的生产！

      这种控制复用的手段是很恐怖的，你认为呢？

      或许你说闪电举这些例子竟是瞎扯，那么闪电只是告诉你自己是如何理解的，你可以保留不同意见，或者留言批评拍砖都可以。

      闪电有时候喜欢从更宏观的方面理解抽象事物，百度的搜索框，为什么只提供一个入口点呢？想想也枉然。

      闪电学习这个的时候也弄了多线程计数器，觉得她更适合说明多线程的问题，所以闪电只想从最简单的问题来说明单例。

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

转载请注明出处：http://levinlee.cnblogs.com/

Mono 2.4.2正式加入了对asp.net mvc项目的支持，也就是说asp.net mvc项目现在也可以在Mono上跑了。asp.net mvc是基于MS-PL协议发布的项目，MS-PL是OSI认可的许可证，GNU也认可它为免费软件许可证，它允许任何人查看源代码、修改源代码并发布修改后的源代码。而且此许可证并不限 制代码只能运行在Windows上，这样就可以将代码移植到其它操作系统，例如Mono（Linux上的.NET）和Monolight（Linux上的 Silverlight）。MonoDevelop有一个插件，可以用来在Linux和Mac OS X上开发ASP.NET MVC程序。

还有一些使用MS-PL许可证的微软项目:

• ASP.NET MVC Open Source
• .NET Dynamic Language Runtime (DLR)
• IronRuby
• IronPython
• Silverlight Toolkit
• Ajax Control Toolkit
• Managed Extensibility Framework (MEF)

也就是说这些项目都可以跑在Mono上的，其中的一些项目已经包含在Mono里，比如IronPython，DLR等。

今天对博客评论功能进行了更新，重点就是解决评论提交速度慢的问题。

另外改进了评论通知机制，当您在其他人的博客上发表评论，如果有人针对您的评论进行回复，系统会邮件通知您。

还解决了回复邮件通知串线、分页方法不合理等问题。

欢迎大家对评论功能进行测试，如果发现问题或者需要改进的地方，麻烦您立即反馈给我们。

问题引出

C#是一种面向过程的算法设计语言,在处理数学计算时显得力不从心。面向集合是一种比较高阶的特性，允许程序直接对集合进行直接处理，而不用显示进行循环调用，不需要指定路径，因此可以大幅提高开发效率，进行并行优化。很多数学软件，如MatLab是面向矩阵的，而开源语言R是面向向量的，SQL是面向关系系的、APL（Array processing language）是一种一种多用途、第三代（3GL）编程语言，在向量、矩阵等各种秩的数组处理上非常简单。SPSS，SAS等都需要大量的集合运算。

本文试图从C#本身的特性出发，用C#模拟面向集合的方法。

更期望C#能向MatLab, APL,R那样直接处理集合运算，进入科学和工程计算领域，为以后的并行计算奠定基础。 

有一列观测值，用List存储，我们现在需要求出每一个观测值的正弦Sin值。

用C#面向过程的语法表示如下： 

求Sin值，是一个繁琐而又重复的问题。我们希望Math.Sin(Collection c)，在不改变已有代码（不扩展Math.Sin）的情况下，自动处理集合，就像在MatLab里面。

 C#是面向过程的，而Matlab是面向矩阵的，SQL是面向关系代数的。关系代数和矩阵，都可以看作集合的特例。（LINQ部分加入了面向集合的特性）

面向过程，需要程序员书写算法的每一个过程和细节，指明执行路径，这主要表现在循环语句的使用上(包括for, foreach, while…)。

面向过程给了程序员最充分的自由和最大的灵活，但其固有的“底层”，导致了开发效率的底下，同时不利于并行计算和系统优化。而在数学中，大部分计算都是基于矩阵（集合），例如图形图像处理，概率论，数理统计，优化控制等等。 所以C#难以胜任运算集中和知识处理，人工智能设计。

由于C#实在是太优美，是目前最艺术的语言，利用C#现有特性，我们可以简单的模拟前面提出的问题    

这样，我们可以在Apply来处理一些关于集合处理的问题。

下面在给出一个处理矩阵的例子：    

使用这个Apply，可以处理矩阵集合相关的计算。

矩阵定义如下： 

再看下面复数的例子： 

使用这个Apply，可以处理复数集合相关的许多计算。

复数类的定义如下： 

从前面三个例子，我们可以看出，集合有多种表示方式，有.net框架中的List，也有自定义的Matrix，同时集合的元素也是多种数据类型，有系统中的值类型，也有自定义的复数Complex类型。 

当然这种算法过于勉强，显然不是我们所需要的。

我们需要的是一个在不更改现有语言的情况下，不扩充Math.Sin函数（试着想想有多少个类似的函数,Cos, Tan, 我们自己定义的各种函数）。系统自动处理集合。也就是说，对于函数    public delegate TOutput Converter<TInput, TOutput>(TInput input);public T1 Func<T1, T2>(T2 e); Func是Converter的实例。只要Func能够处理原子类型，那么就能处理自动所有的原子类型构成的任意集合，而不需要程序员去写多余的代码。

在引用的这篇文章中，作者指出了九个其认为“不够面向对象”的对象。而本人一直不喜欢不是面向对象或者不够面向对象这样的提法，在本人看来，所有的这些对象不过是因为其不够饱满，而在实际的项目设计中，根本没有必要要求所有的对象都是饱满的。对象的饱满程度与对象的设计粒度有关系，简单的说，如果是一个非常简单的项目，比如说输入一个数输出某种算法的结果这样的小练习，一个对象负责交互、计算、计时等等工作是没有任何问题的。但是如果你是做一个计算器，那么你把这些东西都写在一个类型里面，粒度就明显过大了。

仍然用生物界来做例子，将对象比喻成细胞，那么对于原生生物而言，只需要一个细胞（一个对象）就够了，这个细胞可以自行增殖、吸取养分，甚至可以抵御外敌和自由行动。但是对于高级生物而言，则需要大量的细胞协同工作，这些细胞可以是没有行为的（骨骼细胞），也可以是不能增殖的（脂肪细胞），但这些都不影响它们在存在的合理性。

废话不多说，下面随便指出几个所谓的不够面向对象在设计中的合理运用：

1、贫血对象，事实上就是退化成数据结构的对象，对象可以视为是数据结构的扩展，对象=数据+行为。如果一个数据自己没有行为可不可以呢？没有道理不可以的，比如说狗会叫，石头会叫么？石头难道就不是对象了？没有行为的对象最著名的如string，另外如Uri，所有的基元类型也可以视为是所谓的贫血对象。不要以为这样的对象就与OO没有关系，没有石头用什么去打狗呢？说设计是不是合理，取决于这个东西是不是丢失了本来应该有的行为，而不是说没有行为的都不是Object了。

2、管理者对象，其实就是抛弃了数据结构只剩下方法退化成方法组的对象。同上面的对象的存在是合理的一样，只有方法组的对象存在也是合理的。而且非常重要，因为方法是多态的。绞肉机需要自己有肉么？刀子需要自己有苹果么？那么方法组为什么一定要带上数据呢？比如说我们定义一个刀子类，显然这个刀子是不需要自己有苹果的，没有人会new 刀( 一个苹果 )吧？而只可能是：一把刀.切( 一个苹果 )。而且，我们可以方便的class 花刀 : 刀，利用多态的特性来使得我们可以把苹果切成星型、三角形等各种形状。你能说这不是OO么？

3、储柜对象，事实上是一个强类型的Dictionary，这种对象存在的意义与Dictionary存在的意义是一样的（或者说就是1的情况）。既可以作为数据打包的传递，也可以作为一个适配器来对某个抽象的、不存在的东西进行控制。作为Dictionary的用途就不说了，说说适配器的用途。比如说DOM模型中的对象，大部分对象的属性都是R/W的，这样的对象实际上是文档模型的一个适配器，通过修改对象来修改文档。这又有何不可呢？

4、多管闲事的对象，虽然这大多数情况下是抽象的问题，但在一个优秀合理的设计中这种情况也并非不存在。就那篇文章的作者所举的例子而言，完全属于抽象的问题，Pet怎么可能都会CatchRat？这是很滑稽的。但一个类型将继承的方法屏蔽这种情况却“不都是”抽象的问题。比如说我们设计一个类：猫，那么猫一定会吃东西、能跑跳。但是残疾的猫和昏迷的猫呢？那么它们不是猫么？显然它们也是猫，但是并不是所有猫都具备的行为它们都有，这样的情形，就必须在派生类中屏蔽基类方法来实现。而不可能是我们将猫去继承于残疾猫。继承关系的最大原则是抽象关系，具体类型继承抽象类型。其他原则是帮助我们把握抽象关系的方法，而不是必须遵循的原则。

最后关于第8点谈谈，没有专属自己的数据，没有专属自己的行为，就不要一个类型这样的说法显然是不靠谱的，是不是需要一个类型，最重要的是看这个类型有没有意义，而不是这个类型有没有独特、专有的东西。类型的首先在于类型本身而不在于其成员。或者说，正确的设计是先确定类型，然后再设计其成员，而不是将成员列张表然后归纳出几个类型。比如说我们设计一个正方形类，继承于矩形，请问这个正方形是有什么它有而矩形没有的呢？但是这个类型是有意义的，比如说我们有些方法只能对正方形进行操作，就不应该接收一个矩形对象，然后判断这是不是一个正方形。

一、会话信道（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形框架，现在都这样就不想搞另类了。

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