博客园_梁逸晨的IT专栏

Code-First 在SQLServer Compact 4.0 中的应用（一），基础配置

2012-02-09T18:49:00Z

在继续往下看之前，首先一定要保证你的IIS运行于 ASP.Net 4.0 ，这是唯一的要求，SQLServer Compact 4.0只能运行于4.0环境，没有商量的余地。如果做不到，要么改善一下与服务器管理员的人际关系，要么就换服务器。

虽然我也知道有办法可以让 SQLServer Compact 3.5运行于ASP.NET 2.0-3.5，但是，CodeFirst与LINQ一定会有错误发生。

至于那些还在用1.1环境的朋友，我不想说技术问题，只希望你能明白：今年已经是世界末日。

至于桌面应用环境，一样需要.net 4.0环境。

本文的运行环境是ASP.NET Webform 4.0 ，你也可以选择MVC环境。既然标题说了是 SQLServer Compact 4.0，那么如果你的服务器还没有安装SQLServer Compact 4.0的话，别紧张，不需要你安装任何东西。只需要把下面文件放入Bin文件夹就行了：

http://files.cnblogs.com/kvspas/SQLServerCE4_Bin.rar

里面的东西一定很多（主要是64和32都有），肯定有可以去掉的，但是我没那精力去研究哪些是需要的，哪些是可以去掉的，如果你研究出来了，谢谢汇报一下。

然后是配置EntityFramework 4.1 ：我们可以通过Nuget或者手动下载的方式来安装 EntityFramework 4.1 ，这里我推荐后者。

安装文件下载地址： http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8363

如果你没有服务器的配置权限，就把下面的文件放入Bin文件夹就行了：

http://files.cnblogs.com/kvspas/EntityFramework.rar

项目中引用它：

以及，引用System.ComponentModel.DataAnnotations：

接下来就可以开始正题了：

步骤一：创建数据表

不要看那些类似广告的教程吹得天花乱坠，即使是POCO编码，也并非绝对“干净”的，必须至少定义一个特性来标识主键([Key])，要不然的话，我不说，你可以试试看为了保持所谓的“美观”，而把[Key]特性去掉会是什么后果。

    public class LiangyichenDB
    {
        //主键，必须定义
        [Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int index { get; set; }

        public string title { get; set; }

        public DateTime pubdate { get; set; }

    }

步骤二：创建数据库访问对象：

    public class LiangyichenDBContext : DbContext
    {
        public DbSet<LiangyichenDB> Items { get; set; }
    }

以上两个类型需要引用命名空间：
using System.Data.Entity;
using System.ComponentModel.DataAnnotations;

好了，以上两个步骤通用于任意数据库，和 SQLServer Compact 并没有绝对的关系，接下来是开始 配置 SQLServer Compact ：

不需要你去创建实际的数据库文件，你只需要在 Web.Config 的 connectionStrings 中设置这么一段话：

上面虽然说了不需要你创建实际的数据库文件名，但是需要事先保证 App_Code文件夹已经存在，不要问我为什么。

谨记： name="LiangyichenDBContext" ， name的值必须与数据库访问对象同名，同理，不要问我为什么，也不要浪费精力去探讨或者改变什么，你只需要明白太阳一定是从东边升起的，古往今来的种种惨案告诉我们：知道得太多不是好事。

至于数据库文件名，可以任意。

最后，在页面对应代码中添加：

        protected void Page_Load(object sender, EventArgs e)
        {
            var context = new LiangyichenDBContext();

            context.Items.Add(new LiangyichenDB { title = "1", pubdate = DateTime.Now });
            context.Items.Add(new LiangyichenDB { title = "2", pubdate = DateTime.Now });
            context.Items.Add(new LiangyichenDB { title = "3", pubdate = DateTime.Now });
            context.SaveChanges();

            foreach (var i in context.Items)
            {
                output(i.title);
            }
        }

        void output(string str)
        {
            Response.Write(str+"<br />");
        }

行了，运行一下，你就会发现App_Code文件夹中已经自动生成了Database.sdf 文件。

SQLServer Compact 4.0 的 Code-First 基本配置结束。

下面是项目文件下载地址，在VisualStudio2010中启动成功。

http://files.cnblogs.com/kvspas/Webform-SQLServer-Code-First.rar

（注意我说的是“项目文件”，所以你一定需要在VisualStudio2010中打开sln文件运行，不能直接弄到IIS下面启动）

如果第一次运行之后，再去修改、添加、删除表的字段、删除数据库文件，那么程序一定会出错，下一篇再说怎么解决。

本文链接

for与foreach，在遍历属性时的差别，for能够更安全的获取数据

2012-02-03T02:10:00Z

某些类的某些属性，由于实现了IQueryable或IEnumerable，能够更方便、更优美地使用foreach查询。但是在一些特殊情况下，foreach不一定能够查询到准确的值，例如以下情况：

建造一个HtmlTable (runat=server)，至少有一行数据，内容任意，然后再建造一个添加行数据的方法，在每次添加完数据之后，立即使用 foreach(var i in obj.Rows) 查询，这时候就会出现“集合已经更改”的错误。

如果我们换成for(var i = 0; i< obj.Rows.Count;i++)，就可以避免错误发生了。因为for是实时查询，而foreach是调用IQueryable或IEnumerable中的yield return 的后期查询，在实现机制上有所不同。

当然for需要编写更多的代码，在外观上也没有foreach的可读性高，这时候也需要我们根据具体情况具体使用。

本文链接

图解MVC中的路由设置对应的Contorller和View

2012-01-25T19:33:00Z

以上是默认的情况，执行顺序我们这样理解：

1：首先定位到HomeController类。

2：然后定位到Index方法。

关于类的映射：

路由设置中，controller = "Home" 会映射到HomeController类，而HomeController类的类名，我们需要拆分为两个单词去理解： "Home"+"Controller"。路由会查找到前面的那个词语，并绑定之，在这里是属于名称半匹配。

关于方法的映射：

action = "Index" 映射到 Index 方法，是属于全名匹配。

默认的例子可能会带来一个误会：让我们认为 "{controller}/{action}/{id}" ，这条规则一定会匹配 HomeController 类，实际不是这样。

我们在 Controllers 文件夹中添加一个另一个Controller类：TagsController

    public class TagsController : Controller
    {
        //
        // GET: /Tags/
        public ActionResult Index()
        {
            return View();
        }

    }

并且添加对应的View:

@{
    Layout = null;
}
<!DOCTYPE html>
<html>
<head>
    <title>Index</title>
</head>
<body>
    <div>
        this is tags
    </div>
</body>
</html>

然后在浏览器中输入： http://localhost:13812/tags/index/2 ，主机名称部分根据你的实际情况修改，关键是后面的/tags/index/2

看到了不？浏览器中显示的是我们新添加的View的内容。

所以： 路由的匹配是动态的，它绑定的只是某一条地址规则： {controller}/{action}/{id}

地址中的 controller 部分你输入 home，它就映射到 homecontroller ，你输入tags, 它就映射到tagscontroller (只要它们已经存在就行)

action部分也是一样的道理，如果你输入 /home/about，那么它就映射都homecontroller类的abut方法。

但是执行顺序是一定的：首先映射类，然后映射方法。

然后我们来说说路由设置中的的那个匿名对象，它的作用是指定默认情况下应该映射到哪个类的哪个方法，什么是默认情况呢？看下面的地址：

/home

/hone/index

/home/index/1

它们都会映射到：controller = "Home", action = "Index"

如果我们把匿名对象去掉，把路由修改成这样：

            routes.MapRoute(
                "Default", // Route name
                "{controller}/{action}/{id}"
            );

这时候我们就只能访问 /home/index/1 ，也就是/类名/方法名/id，三个参数一个都不能少，id可以修改为任意字符串。因为此时就是严格匹配路径参数

本文链接

WebForm中搭配母版页和用户控件页时候的事件加载顺序，附测试程序

2012-01-02T16:56:00Z

在生产环境中，一个内容页(aspx)可能会包含数个用户控件(ascx)，而每个控件可能都会涉及到数据库访问。

如果在内容页、母版页、控件页中各自使用自己的数据库访问方法，会造成很大的运行成本。

这样的情况下，我们就应该重用数据库连接了，但是在这之前，需要搞清楚内容页、母版页和控件页的加载顺序。

这篇文章中先给出它们的加载顺序，数据库重用部分留下一篇中再详解

以下是我测试出来的结果，阅读顺序是从上到下：

测试程序下载地址：http://files.cnblogs.com/kvspas/form_master_control.zip

执行结果就是图中的模样，我的开发环境是asp.net4.0，理论上你可以把它修改到3.5和2.0。

本文链接

新浪OAuth网站登陆连接，请求access_token时遇到21323 miss client id or secret 的解决方案

2011-12-29T23:11:00Z

本文的环境仅仅是针对最新的新浪oauth2.0，早期的1.0方式我不太了解，也不在本文的范畴内。

解决方案给出两种： 1，描述解决思路，各位自己去实现。 2，给出我开发好的asp.net 4.0 dll，直接傻瓜化加载使用。

当时，我把电脑屏幕翻转了180度，想看看新浪的文档里面是不是有些什么隐藏说明（因为有先例：九阳真经就是这么来的），要不然为什么我已经正确提交了各个POST参数，依然得到： '{"error":"invalid_request","error_code":21323,"request":"/2/oauth2/access_token","error_uri":"/2/oauth2/access_token","error_description":"miss client id or secret"}' 这样的错误提示。

一切都已经按照文档的说来做了，参见：http://open.weibo.com/wiki/OAuth2/access_token。我自视水平不高，虽然是个初学者，但是这样的配置还是能够搞定的，可结果偏偏还是错误。

我也不想再列举自己的各种证据了，需要搭建的环境太麻烦，没那功夫，反正遇到这问题的人多的是，搜一搜别人的例子就知道，都是一样的遭遇。

我始终认为是我的错误，而不是新浪的错误，所以，电脑屏幕翻转了180度，没发现什么特别的隐藏说明，接着又拿一块大镜子来看镜像，还是没发现什么，最后使出了绝招：把文档的所有文字按照奇数和偶数都排列着读一遍，依旧无解。终于：我开始觉得不是我的错了，而是新浪的错。

文档中有这么一句提示：

HTTP请求方式：POST

这句话太简单了，你们想要人家POST什么？让人认为所有的参数都要作为POST发送过去。可事实偏偏不是这样的， OAuth的服务端只要看到本次提交的行为是POST就行，至于POST集合里面有没有数据，有些什么数据，它才不会管，所以，无论我们在POST里面添加了什么键|值、无论怎么切换顺序，都是错误的，因为它就没有去读取。

解决办法只有本着死马当活马医的态度：乱搞！

最终还是让我发现了----需要使用GET和POST的混合方式来提交：

提交的地址应该是：

"https://api.weibo.com/oauth2/access_token?client_id={0}&client_secret={1}&grant_type=authorization_code&code={2}&redirect_uri={3}"

请求方式：POST

POST中的数据：空！

0，1，2，3 对应你自己的参数值

就是这样，终于正确获得token值，服务器只管你的method是POST就行了，你的实际参数都是在GET里面的。

顺便提一下：如果采用basic方式在http头中添加key和secret，最后依然是大同小异的错误，只不过是提示变成了找不到你的redirect_uri参数。

好了，解决思路说完了。如果你不愿自己动手，并且你也和我一样是ASP.NET 4.0开发的话，可以接着往下看：

下载地址：http://files.cnblogs.com/kvspas/SinaOAuth_20111230_v1.zip

组件中已经封装好了直接获取用户基本信息的功能，并且已经强类型化。

组件的一部分功能使用了JSON.NET库(http://json.codeplex.com/)

使用办法：

首先，必须保证运行环境是4.0，因为解析JSON的方式涉及到dynamic类型

1：页面1

using SinaOAuth;

//第一步,将用户引导到新浪微博登陆地址
var login = new SinaOAuthLogin("你的key", "你的回调地址");

Response.Redirect(login.SinaOAuthLoginUri);

2：页面2

using SinaOAuth;

//第二步，这个页面来自新浪跳转过来，也就是上一步中你设置的回调地址
//本页面的url格式应该是这样的：
//http://www.abc.com/sinaoauth.aspx?code=427bbf62b4b91339951b436c4880e9ef

var code = Request.QueryString["code"];

SinaOAuthApi s = new SinaOAuthApi("你的key", "你的secret", "你的回调地址");

var tokenValue = s.RequestTokenData(code); //包含了uid、expires_in、access_token，请求其它API时候使用

var user = s.RequestUserInfo; //获取用户基本信息

Response.Write(user.name);

好了，就这么简单。最核心的身份验证部分已经帮你通过了，其它的API就由你自由发挥了。

使用其它语言的朋友请参照解决思路自行编码。

这是新浪API团队设计思维上的一个BUG，之所以说是“设计思维”上，是因为没有对生产环境的运行带来坏处，但是这样的文档说明存在二义性、POST不是POST，GET不是GET的机制，难以专业化，这个系统还有很大的改善空间。

本文链接

Team Foundation Server 2010配置数据库遇到“与某个指定的域或工作组帐户冲突”的解决方案

2011-12-11T04:32:00Z

如果修改了计算机名或者工作组或者设置了新的域，安装和配置Team Foundation Server的时候很可能遇到如下的错误：

错误 [ 配置数据库 ] TF255507: 以下 SQL Server 登录的安全标识符(SID)与某个指定的域或工作组帐户冲突: WIN-9ILOU7R0E13\Administrator。域或工作组帐户为: STORAGESERVER\Administrator。选择的用于承载 Team Foundation Server 数据库的服务器为: StorageServer\sqlserver。
可以通过重命名冲突的登录来解决此问题。为此，请在运行 SQL Server 的计算机上打开命令提示符，并执行以下命令:
sqlcmd -E -S "StorageServer\sqlserver" -Q "ALTER LOGIN [WIN-9ILOU7R0E13\Administrator] WITH NAME = [STORAGESERVER\Administrator]"
有关详细信息，请参见 Microsoft 网站上的以下页面: http://go.microsoft.com/fwlink/?LinkId=183408

一开始没有认真看错误信息，于是到处搜索解决办法，不是叫你杀毒就是叫你重启，包括某个知名的社区在内，除了假惺惺的“你好”二字外，和百度知道没有本质区别。

回来硬头皮搞，过程就不详述了，其实，错误描述已经包含了答案，只不过我们的心里作用让我们很少去注释他们。

请注意里面的：sqlcmd -E -S "StorageServer\sqlserver" -Q "ALTER LOGIN [WIN-9ILOU7R0E13\Administrator] WITH NAME = [STORAGESERVER\Administrator]"
这么一句话，以管理员身份打开命令提示符，一定要用管理员身份，然后复制进去执行，问题就解决了。

*注：上面这条命令是我自己的机器参数，不要复制我的命令，要看你自己的错误信息相对位置。

本文链接

delegate详细解析

2011-05-05T21:32:00Z

Delegate实际上是一个类型（class）。这一点我们可以做一个实验例子。

using System;

delegate void Print(string message);

sealed class Testing

{

public static void Execute(Print p)

{

p("testing");

}

sealed class Program

{

static void prt(string str){ Console.WriteLine(str); }

static void Main(string[] args)

{

Testing.Execute(prt);

}

然后我们通过IL代码观察：

代理，也就是delegate Print 实际上是一个sealed class ，见 特征1 ，继承于System.MulticastDelegate

特征2 更明显，直接说明了Print就是一个class

构造函数和两个多线程方法我们暂且不谈，这里的重点是它具备一个Invoke 方法，类型是void, 签名类型是string 。

我们用两个方法来试探一下这个Invoke是什么，首先，我们通过代码调用顺序，查找一下Testing 类的静态方法 Execute(Print p) 做了些什么：

实际上调用了Print对象的Invoke 方法，参数就是之前压入栈的“string”。这下我们明白了， Invoke方法就是我们定义的 delegate void Print(string message); 的真身。

再来一个方法证实一下这个猜测，我们修改一下C#源代码：

using System;

delegate void Print(string message);

delegate void Dele2(int i, DateTime d); //增加一个新的代理

sealed class Testing

{

public static void Execute(Print p , Dele2 d)

{

p("testing");

d(10, DateTime.Now);

}

sealed class Program

{

static void prt(string str){ Console.WriteLine(str); }

static void ptr2(int i, DateTime d)

{

Console.WriteLine(string.Format("{0},{1}",i,d));

}

static void Main(string[] args)

{

Testing.Execute(prt,ptr2);

}

然后我们再来看看生成IL代码：

这下勿须置疑了，我们可以这样子认为：

Delegate 实际上就是一个特殊的类型，只不过是我们的声明的时候可以简化写法，系统实际上还是会编译为sealed class , 在这个特殊的类中，会使用一个拥有相同签名的方法来实际执行。

最后，做一次验证，我们再修改一下代码：

using System;

delegate void Print(string message);

delegate void Dele2(int i, DateTime d);

sealed class Testing

{

public static void Execute(Print p , Dele2 d)

{

p.Invoke("testing"); //改动点

d.Invoke(10, DateTime.Now); //改动点

//我们直接调用它们的Invoke方法

}

sealed class Program

{

static void prt(string str){ Console.WriteLine(str); }

static void ptr2(int i, DateTime d)

{

Console.WriteLine(string.Format("{0},{1}",i,d));

}

static void Main(string[] args)

{

Testing.Execute(prt,ptr2);

}

成功执行：

本文链接

LINQ查询中，对于值类型的比较应注意使用Value属性

2011-05-01T12:23:00Z

例如，对于入住天数，如果我们使用：

data.Where(o => o.custom_livedays.Equals(_livedays));

在语义上是没有问题的，但是不会得到我们想要的答案，正确的写法是：

data.Where(o => o.custom_livedays.Value.Equals(_livedays));

仅对于值类型是如此，如果是引用类型，例如string, 那么就用不着value属性了。例如：

data.Where(o => o.custom_name.Equals("字符串值"));

本文链接

从古城5号到变量命名规范，多一些抽象也许会更好

2011-04-12T08:07:00Z

昨天我走在丽江古城里，路过一家店，当时那条路的名字忘记了，暂且先叫“A路”吧，而那家店面就叫“A路5号”，它的门牌号确实也是A路的5号。这么一看就联想到问题了：

1 假如以后搬迁店址

2 假如以后街道改名

还有更多的假如发生的情况，就不一一列举了，只要发生其中一个，那么店名与门牌号就不再匹配了，进一步地，也许隔壁或者对面就变成新的"A路5号"了。

当然这样的事情有很多的解决方案，实际上发生那些事情的可能性也微乎其微。

但是如果把这样的事情放到软件架构设计中，那么出大问题的机率就不容忽视了。例如我现在正在设计windows phone7的一个网络访问模组，一开始我是想把namespace命名为：Kvspas.WindowsPhone7.Net 。但是后来又去掉“7”，改为Kvspas.WindowsPhone.Net. 因为下一代WindowsPhone也一样需要使用它，那时候“7”这个数字就不适合了（街道改名了）。再后来，WindowsPhone这个词汇还是不合适，因为同属于SilverLight与XNA架构的浏览器SilverLight和桌面脱机SilverLight中也需要使用它，于是又改为了Kvspas.SmartDevice.Net。看似可以了，最后还是觉得有些地方不对，SmartDevice 表示智能设备，泛指手机、平板电脑等随身携带的设备，与通用型windows系统还是相差甚远的。最终，选用了SmartClient 这个词：Kvspas.SmartClient.Net 。取智能客户端之意，Client一词可指硬件，也可指软件，而Device却只能表示硬件。

严谨的命名法在整个软件架构中相当重要，直接关系到开发者自己在三个月后还能不能明白当初开发的这个模块是干什么用的。一款可用性产品包含很多很多的模组，胡乱命名只能够带来“破窗户效应”。 14年前，16系统开始升级到32位系统的时候，当时的工程师把系统盘中那个文件夹取名为System32，“32”一词就是典型的错误例子（在语义上绑定了CPU架构，其实没必要）。今天不得不用一个新的SysWOW64文件夹来区分64位系统的主文件。以及Program Files(x86)区分32位程序集。

进一步说，我们平时新建一个文件夹，无论保存什么东西，都不应该使用它默认的“新建文件夹(1)”、“新建文件夹(2)”这样的名称。一旦这样的文件夹多了，自己的很多文件就再难以维护整理了。

本文链接

在继承机制中引用继承权校验

2010-08-31T15:05:00Z

引言：在某些特殊情况下，我们需要把类型设计为public class（这是前提条件，所以internal 声明无效），但是却又不想给人无条件调用或者继承该类，这时候我们可以把类设计为 public abstract class，就避免了直接创建它的对象，但是不想被无条件继承，则要动一番脑经了。首先，abstract class 就是设计来被人继承的，我们不可能用sealed 来声明它。

这样的情况在实际运用中还是存在的：比如某个DLL中的某些公共类，只有具备某些权限的开发人员才能够继承之，或者是某些收费组件，必须提供序列号，才能够继承调用。

在本文的简单例子中，虽然通过DLL反汇编可以间接获取继承权序列号，但是相信在实际开发中，我们不可能通过一个简单的字符串判断就如此了事，这是另一个话题了。不在本文讨论范畴。

正文：在继承机制中，父类的构造函数一定先于子类被初始化。就像如下的IL所示：

基于这样的原理，我们可以先尝试在父类构造函数中加入序列号判断（为了方便描述问题，在这里暂且用简单的”123456”作为序列号示例），一个简单的示例：

基类提供了一个方法：DoSomething()，在实际中也许会是一组甚至好几组方法，其内部算法不会对外公开，外部子类需要一定的权限才可以通过继承基类来间接调用。

    public interface IMethodable
    {
        void DoSomething();
    }

    public abstract class Parent : IMethodable
    {
        const string _mykey = "123456";

        public void DoSomething() { Console.WriteLine("doing......"); }

        public abstract string ExtendsKey { get; }

        public Parent()
        {
            if (!(ExtendsKey.Equals(_mykey)))
            {
                throw new Exception("拒绝继承");
                //或者把本次错误记录到日志
            }
        }
    }

    public sealed class Child1 : Parent
    {
        public override string ExtendsKey
        {
            get { return "123456"; }
        }
    }

子类必须提供一个序列号，如果序列号不对，父类构造函数在运行时抛出错误，整个程序运行中断。

至此，我们在理论上解决了问题。

但是在实际应用中，这个算法存在几个缺点：

1. 每次运行程序，继承机制都会进行一次String. Equals判断，而一个有意义的程序在正常运行的时候是不需要反复作出错判断的，并且String. Equals每次都会构造一个新的字符串，这样的效率很难让人接受。

2. 在DLL内部如果有别的类需要继承Parent基类的时候，同样需要进行继承权校验，例如：

    public sealed class InnerChild : Parent //DLL内部的类，没有必要进行继承权校验，但是却不得不这么做
    {
        public override string ExtendsKey
        {
           get { return "123456"; }
        }
}

这样的做法就更愚蠢了。

3. 更甚之，无论是DLL内部或者外部，当有多个子类需要同时继承自Parent基类的时候，每一个子类都需要重写ExtendsKey 属性；倘若我们通过以下方法：

    public abstract class AbstractChild : Parent //增加一层中间类
    {
        public override sealed string ExtendsKey
        {
           get { return "123456"; }
        }
    }

    public sealed class Child1 : AbstractChild
    {
    }

    public sealed class Child2 : AbstractChild
    {
    }

看似可以避免重复代码，但同时却多出了一个缺陷：如果外部程序直接继承 AbstractChild ，便绕过了序列号判断，则整个安全机制便形同虚设。

综上所述，我们需要对整个算法进行重构：避免多余判断、避免重复代码、保证安全机制。

我们对Parent类进行分解，让继承权判断和业务方法分离：

    public interface ISecuritable
    {
        string ExtendsKey { get; }
    }

public abstract class InnerMethod : IMethodable  //它的子类是public，所以它也必须是 public
    {
        internal InnerMethod() //internal声明的构造函数保证了外部程序集不可继承该类
        {
            Console.WriteLine(this.GetType().ToString());
        }

        /// <summary>
        /// 实际业务逻辑放在这里
        /// </summary>
        public void DoSomething() { Console.WriteLine("doing...."); }
    }

    /// <summary>
    /// 必须有继承权才能够继承
    /// </summary>
    /// <typeparam name="Key"></typeparam>
    public abstract class Parent<Key> : InnerMethod
        where Key : ISecuritable, new()
    {
        private static string _mykey
        {
            get
            {
                return "123456"; //假设实际中这个验证码是通过数据源获取，这里简化之
            }
        }

        static ISecuritable _key;

        public Parent()
        {
            if (_check())
                Console.WriteLine("通过继承权检查");
            else
                throw new Exception("error");
        }

        static Func<bool> _check = () =>
            _key != null ? true :
                (_key = new Key()).ExtendsKey.Equals(_mykey) ? true :
                    "".Equals(_key = null);

    }

如此一来，我们在DLL内部可以这样实现业务逻辑：

    public sealed class InnerClass1 : InnerMethod
    {
        //在DLL内部的继承法，就不存在任何性能损耗了。
    }

    public sealed class InnerClass2 : InnerMethod
    {
        //实际的开发中，这就相当于“官方提供功能”。
    }

其设计图如下所示：

InnerMethod 作为带有 internal构造函数的 public abstract class , 外部程序只能够看到它，但是却无法调用和继承它。

此时Parent只作为 InnerMethod 的对外封装，继承Parent需要有凭据（泛型参数Key），其外部调用如此实现：

    public class SecurityFactory : Isecuritable   //相当于一个凭据
    {
        public string ExtendsKey { get { return "123456"; } }
    }

    class OutsideClass:Parent<SecurityFactory>  //在实际中，这就相当于第三方开发插件。
    {
    ｝

虽然在Parent中我们不能完全去掉if判断，但是在成功的继承中，仅需要判断一个静态对象是否等于null （_key != null），相比起之前的String.Equals，其性能损耗已经小到可以忽略不计了。

至此，我们解决了所有问题，下面是完整的DLL代码和客户端代码。如果哪位有更好的实现方法，欢迎讨论。

    public interface ISecuritable
    {
        string ExtendsKey { get; }
    }

    public interface IMethodable
    {
        void DoSomething();
    }

    public abstract class InnerMethod : IMethodable  //它的子类是public，所以它也必须是 public
    {
        internal InnerMethod() //internal声明的构造函数保证了外部程序集不可继承该类
        {
            Console.WriteLine(this.GetType().ToString());
        }

        /// <summary>
        /// 实际业务逻辑放在这里
        /// </summary>
        public void DoSomething() { Console.WriteLine("doing...."); }
    }

    /// <summary>
    /// 必须有继承权才能够继承
    /// </summary>
    /// <typeparam name="Key"></typeparam>
    public abstract class Parent<Key> : InnerMethod
        where Key : ISecuritable, new()
    {
        private static string _mykey
        {
            get
            {
                return "123456"; //假设实际中这个验证码是通过数据源获取，这里简化之
            }
        }

        static ISecuritable _key;

        public Parent()
        {
            if (_check())
                Console.WriteLine("通过继承权检查");
            else
                throw new Exception("error");
        }

        static Func<bool> _check = () =>
            _key != null ? true :
                (_key = new Key()).ExtendsKey.Equals(_mykey) ? true :
                    "".Equals(_key = null);

    }

    public sealed class InnerClass1 : InnerMethod
    {

    }

    public sealed class InnerClass2 : InnerMethod
    {

    }

    public class SecurityFactory : ISecuritable
    {
        public string ExtendsKey { get { return "123456ee"; } }
    }

    class OutsideClass:Parent<SecurityFactory>
    {

        public static IMethodable Create
        {
            get
            {
                var item = new OutsideClass();
                return item;
            }
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IMethodable chi = new InnerClass2();
            chi.DoSomething();

            var outside = new IMethodable[]
                              {
                                  OutsideClass.Create,
                                  OutsideClass.Create,
                                  OutsideClass.Create
                              };

            foreach (var i in outside)
            {
                i.DoSomething();
            }
        }
    }

本文链接