在 C# 或 Java 中，我们可以使用诸如 StringBuilder, StringBuffer 等方式对大量字符串进行拼接操作。当然，我们也可以直接使用 字符串连接 (+=) 的方式进行拼接操作。但是，两种主要方式在效率上有何区别呢？我们是否需要针对这两类方式进行区别场景的使用呢？针对于此，我做了如下测试，以证明两种不同方式连接字符串的效率临界值。（关于Java中StringBuilder和StringBuffer的区别，可以参阅这篇文章）
测试方法是：重复连接字符串 “Hello World!” 1次到40次，在每次连接的过程中都分别采用 String Connection (+=) 和 StringBuilder 的 Append()方法进行1000次，并分别计算出两种方法在这1000次运算过程中的获胜比率。通过多次试验，得到如下统计：
第一次：
Continue reading
（如您转载本文，必须标明本文作者及出处。如有任何疑问请与我联系 me@nap7.com）
ADFS 相关开发技术的中文资料相对匮乏，之前在弄这个东西的时候搞的比较辛苦，因此总结此文档，以解后人之忧。
本文会首先介绍与联合身份验证有关的概念及相关的系统设计意图，随后会对 ADFS 联合身份验证的配置过程、结构及处理流程进行阐述。然后会基于已有的系统提出一个支持多 ADFS 联合身份验证的改进实例，并对其结构及处理流程进行阐述。最后会对开发过程中所遭遇的一些问题进行介绍。真诚希望本文能够帮助读者较快地了解联合身份验证的相关知识。
联合身份验证（Federated Identity）是一种用户身份的验证方式，这种验证方式通过把用户身份的验证过程与被该用户访问的服务提供商（SP，Service Provider，如我们自己的站点）进行逻辑分离，在保证用户身份信息被隔离在用户所属系统的内部的同时，为受信任的服务提供商提供所需要的用户信息。
当服务提供商需要对用户的身份进行验证时，会将相关的验证过程转交给身份验证提供方（IdP，Identity Provider，如AvePoint域的 AD FS 验证服务），当用户经由身份验证提供方成功登录后，身份验证提供方会将用户的身份验证凭据和用户相关的信息返还给服务提供商，从而实现服务提供商对于用户身份的验证，以及对于用户信息获取。
常见的联合身份验证的实现有SAML、OAuth、OpenID等方式，本文主要介绍的是基于Claims和SAML 2.0的 AD FS 联合身份验证。在基于Claims的联合身份验证的过程中，当身份验证提供方完成对于用户身份的验证，返还用户的相关信息时，其数据信息实体被称之为令牌（Token），其中的相关信息字段被称为声明（Claims）。令牌保证了用户身份的真实性，并包含了实用信息，其结构如下图所示。
以下内容是我在公司作为新人培训讲师时对于作业的一次评价，简单介绍了双解锁的作用，可以作为一个简单的参考。
大家可以思考这样一个问题，一个程序可以对应多少个日志文件？对于我们这个小程序来说1个就够了，很多同学在设计Logger类的时候都是在构造方法或初始化方法中生成日志文件的，也就是说，这基本上等价于一个Logger的实例对应一个新的日志文件（或重新对同一文件重新开启流）。
Logger myLogger = new Logger(@“D:my.log”);
如何才能阻止Logger被随意的new出实例呢？我们可以修改Logger的构造方法，让构造方法成为private的，这样就能实现谁都不能new出Logger实例的目的了。但是，访问修饰符（如private）只是影响类之外的使用，对于Logger类的内部，是不会受到private的影响的，也就是说，我们依然可以在Logger类中使用new来创建实例，这正是我们想要的，我们可以为用户提前创建好一个实例，并作为这个类的静态成员存在，从而得到这样一个Logger类：
Continue reading
