项目中很多业务对象的数据表中都具有Status字段，有人使用int型保存Status，有人使用varchar型。
无论使用int还是varchar，对于Status的多选查询都是不易应对的。举例，常规思维下对CustomerStatus的Enum设置如下：
[Serializable]
public enum CustomerStatus
{
New = 0,
Active = 1,
Overdue = 2,
Suspended = 3,
Closing = 4,
Closed = 5
}
在数据库中以int形式存储了Status值。
如果我在页面中想一次搜索状态为Active，Overdue和Suspended状态的Customer，该怎么办？程序是不是得把这三个状态值
拼成字符串传递给SQL去处理？虽然能实现，但是相当低效。
现在给出一个标准解决方案：
(1). 所有可能被用作搜索条件的枚举都应按如下位运算方式定义。
public enum CustomerStatus
{
New = 1,
Active = 1<<1,
Overdue = 1<<2,
Suspended = 1<<3,
Closing = 1<<4,
Closed = 1<<5
}
(2). 在数据库设计时，Status的字段必须为int型。
这样当我们做多选查询时@Status的Value= CustomerStatus.Active | CustomerStatus. Overdue| CustomerStatus. Suspended
(3). 查询语句如下：
Select *
From Customer
Where [Status] & @Status = [Status]
如果@Status可为null时，
Select *
From Customer
Where ( @Status is null Or [Status] & @Status = [Status])
用这样一条简单的语句，就可以获取到所有符合@Status要求的数据行。
目前，随着网页内容越来越绚烂，访问速度却令人越来越不满。实践证明，正确设置Http Response Header中的Expires头将有助于提高网页访问速度。
我们的网站中往往包含大量的页面组件，比如图片、样式表文件、JS脚本文件和Flash动画。这些组件的变化频率非常低，尤其是那些构成网站基本框架的组件，
几乎不会发生变化。我们可以将这些变化率很低的组件看作静态内容，利用IIS的内容过期机制和浏览器的本地缓存机制将它们在访问者的电脑硬盘中保存一段时间。
当访问者访问你的网站时，如果这些存在本地的静态内容没有过期，浏览器会从本地硬盘中装载，而不去向服务器发出请求。
如果你使用Fiddler这样的工具跟踪网页访问，你会清楚地看到虽然只是访问一个页面，但是发出的Http请求和应答却不止一个。网页中的每张图片，每个
JS脚本文件，每个CSS文件，都会引发一次请求和应答。因此如果想让网页的访问速度快起来，减少Http的请求数量，降低从服务器下载内容的次数是有效途径。
而使用了内容过期机制后可以就实现这样的目的，这就是使用内容过期机制的意义。
大多数的Web开发者都玩过IIS 6或IIS 7，但是又有多少人仔细观察过HTTP Headers或HTTP Response Headers标签中的内容呢？此处我以IIS 6 为例，
默认情况下此标签中的界面如下图：
此时，如果向该网站的一个网页发出请求，该网页中包含了一张图片的链接，那么在获取到该网页的HTML文档之后，浏览器会继续对这张图片发出请求，该请求的响应在Http Response Header中如下表达：
HTTP/1.1 200 ok （表示服务器找到了此图片并正确响应）
Date:Thu, 04 Feb 2010 08:25:38 GMT （响应的时间，格林尼治时间）
Last-Modified:Wed, 03 Jan 2009 01:55:06 GMT（图片最后被修改的时间，格林尼治时间）
这张图片会被浏览器保存在本地硬盘的IE临时文件夹中。使用同一个浏览器窗口在同一个会话中再次访问到这个页面，
则页面中的组件都不再重新请求。
当在这台机器上打开另一个浏览器窗口（另一个会话）又一次访问此页面时，由于这张图已经在本地保存了，但是浏览器
刚才的响应中并没有规定内容的过期机制，因此浏览器仍会向服务器发出一次请求：
If-Modified-Since: Wed, 03 Jan 2009 01:55:06 GMT （询问服务器，我本地这张图片的最后修改时间是这个，在此时间之后你那有没有更新的版本？）
If-None-Matched: "abdkfkdkdkdjkjkfkfd" （这是一段ETag编码，是服务器端给该组件的唯一标示）
服务器收到请求后检查被请求的图片，发现它的最近修改时间还是Wed, 03 Jan 2009 01:55:06 GMT ，于是响应请求：
HTTP/1.1 304 Not Modified （请求的图片找到了，并且没有被改变过）
Date:Thu, 04 Feb 2010 08:25:38 GMT （响应的时间）
浏览器收到这个响应就知道它可以放心地使用本地存储的这张图片了，不必再从服务器重新下载该组件。
由此可见，IIS Http Headers标签的默认设置是不禁止浏览器缓存的，但是也没有告诉组件保存过期的时间，因此浏览器将组件保存在本地后，
每次访问都会询问服务器此组件是否过期，如果没过期则使用本地保存的内容，否则从服务器下载内容。 可以看出它只减少了从服务器下载内容的次数，
并没有减少向服务器发出请求的次数，请求和响应依然耗费了时间。
在IIS中定位到网站存放图片的文件夹，然后打开属性窗口，在HTTP Headers中做出如下选择，要求组件的过期时间为本次请求后1天，也就是在本地缓存86400秒。
打开浏览器，首次访问该网站的一个网页，该网页中包含一张图片的链接，于是该图片请求的响应在Http Response Header中如下表达：
HTTP/1.1 200 OK （表示服务器找到了此图片并正确响应）
Cache-Control: max-age=86400 （从本次请求时间算起，允许该图片在本地缓存86400秒）
Date: Sat, 14 May 2011 08:09:29 GMT （响应的时间，格林尼治时间）
于是，只要是在1天之内，使用本机的浏览器打开这个网页，都不会再对这张图片发出请求，而是直接使用本地缓存中的这张图片。可见，减少了不必要的HTTP请求，
提高了网页的响应速度。
很多网站框架性的组件都是长期不变的，因此我们可以设置更长的过期时间，如下所示：
打开浏览器，首次访问该网站的一个网页，该网页中包含一张图片的链接，于是该图片请求的响应在Http Response Header中如下表达：
HTTP/1.1 200 OK （表示服务器找到了此图片并正确响应）
Date: Sat, 14 May 2011 08:50:12 GMT（响应的时间，格林尼治时间）
Expires: Mon, 23 May 2011 16:00:00 GMT (该图片的本地缓存到2011年5月23日16点为止，格林尼治时间)
那么这意味着只要在5月23日16点之前，在本机上访问该网页，都不会再对此图片发出请求。
有人担心如果这样设置过期机制，一旦对这些组件做了更新，访问者将不能收到变化，那岂不是也很遗憾。其实这有两方面的解决方式：
一方面是网站的开发方，应该对图片，样式表文件和JS文件的命名方式进行改进，比如在文件名上加入版本号，这样你一旦修改了组件内容，
就应该使组件拥有新的名称，于是浏览器会发现本地没有对这个组件缓存过，自然就会发起请求。
另一方面，访问者可以通过浏览器的刷新功能强制对网页中的组件重新发起请求。即使设置了过期机制，浏览器的刷新功能仍然会对所有页面组件
发出请求的。
总结，本文的目的就是阐释浏览器本地缓存与Web服务器缓存过期机制之间的交互关系，以及如何通过这种方式达到对性能的提升。
根据《高性能网站建设指南》一书中的统计，从浏览器向一个网页发出请求算起，获得网页的HTML文档的时间只占整个页面应答完成时间的
5%，而剩余的95%时间全部是在请求和下载页面中的各个组件。因此减少对页面中组件的请求和下载，有效地利用浏览器缓存机制是十分有意义的。
1. 程序集由程序集元数据、类型元数据、中间语言代码和资源构成。其中程序集元数据的一个重要组织部分是程序集清单，
它描述了本程序集和引用该程序集所需要的所有信息，并列出了所有的依赖关系。清单由以下部分组成：
(1).标识（名称、版本、文化和公钥）。公钥用于惟一地标识程序集。
(2).属于该程序集的一个文件列表。一个程序集可以拥有一到无数个文件。
(3).该程序集引用的程序集的列表。在程序集清单中说明了在程序集中使用的所有程序集，以及它们的版本号和公钥。
(4).一组许可请求---运行该程序集需要的许可。
(5).导出的类型，这些类型是在程序集引用的模块中定义的。
2. 在一个程序集中可以有不同的命名空间，一个命名空间也可以分布在多个程序集中。
3. 程序集分为私有程序集和共享程序集。在引用私有程序集时，如果程序集是个exe文件，不能用添加引用的方式引用它，
应该把它手动拷贝到目标目录下。如果是.dll文件可以使用添加引用的方式，引用之后系统会自动在目标目录下创建该程序集的副本，
无需手动拷贝。对于共享程序集，则需要将其安装到全局程序集缓存中，gacutil.exe工具可以在安装程序的脚本中调用。
另外，如果查看全局程序集缓存，可以打开C:\Windows\Assembly文件夹查看。
gacutil /l 显示全局程序集缓存中的所有程序集。
gacutil /i mydll 把共享程序集mydll安装到全局程序集缓存中。
gacutil /u mydll 卸载mydll程序集。
引用共享程序集的方法和引用私有的dll程序集的方式是一样的，只是系统不会再把dll的副本拷贝到你的目标目录下，
而是从程序集缓存中加载该程序集。
4.程序集的强名
共享程序集最关键的是要有一个全局惟一的名称，这个名称在.NET中叫做强名。强名由以下部分组成：
(1).程序集本身的名称
(2).版本号。有了版本号，可以同时使用同一个程序集的不同版本。不同的版本可以同时存在，并可以同时加载到同一个进程上。
(3).公钥，它可以保证强名称的独一无二。它也可以保证引用的程序集不会被篡改或代替。
(4).文化。
创建强名文件：
在命令行使用sn –k mykey.snk 就可以生成一个公钥/私钥对，并把它存到snk文件中。
私钥用来为组件进行数字签名，公钥被引用该程序集的程序验证该程序集时使用。同时，公钥也成为了程序集强名的一部分。
具有强名的程序集，通过ildasm反编译工具查看时，可以在程序集清单中看到这个公钥。
5. 关于服务器组件（Enterprise Services）
(1).服务组件需要有强名称。
(2).应当在"全局程序集缓存"(GAC) 中注册服务组件，因为这些组件是系统级别的资源。服务器应用程序要求安装在 GAC 中，
库应用程序则不要求这样（但是建议安装在 GAC 中）。
(3).您可以通过延迟注册自动向 COM+ 注册服务组件，也可以通过 Regsvcs.exe 实用工具手动注册。
自动注册（部署）：
如果启动了使用服务组件的.NET客户应用程序，就会自动配置COM+应用程序。所有派生于ServicedComponent的类都是这样。
自动部署的一个重要的缺点是，在自动部署时，客户应用程序需要有管理权限。如果客户应用程序是ASP.NET应用程序，
ASP.Net运行库一般没有管理权限。所以自动部署仅用于开发阶段。因此，对于开发阶段来说，这带来了很大方便，在每次创建了
服务组件之后，都不用手动部署。
手工注册（部署）：
使用命令：regsvcs SimpleServer.dll就可以把程序集SimpleServer注册为一个COM+应用程序。
如果想学习Asp.Net2.0的异步页技术，那么一定要仔细阅读http://www.microsoft.com/china/MSDN/library/default.mspx?mfr=true，并且下载它的源代码仔细揣摩。全文共介绍了3种实现异步页的编程模型，且功能一种比一种强大。多余的我就不多说了，直接看最后一种模型：使用PageAsyncTask类、RegisterAsyncTask方法、ExecuteRegisteredAsyncTasks方法和TimeoutAsyncOperation方法注册并执行异步任务，并针对长时间无响应的情况调用超时处理方法。原文所提供源码的AsyncPageTask.aspx.cs文件详细示例了使用这个模型实现异步页的方法。
这个模型最大的好处在于可以在一次页面请求中处理多个异步任务，并且还可以用超时处理来避免在执行异步操作时出现的无响应情况。原作者仅仅在Page_Load中注册了一个异步任务，那么我们仿照他的做法，再注册一个异步任务，如下所示：
<%@ Page Async="true" AsyncTimeout="5" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="AsyncPageTask.aspx.cs" Inherits="AsyncPageTask" Title="Untitled Page" %>
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
PageAsyncTask task = new PageAsyncTask(
new BeginEventHandler(BeginAsyncOperation),
new EndEventHandler(EndAsyncOperation),
new EndEventHandler(TimeoutAsyncOperation),
null
);
PageAsyncTask task1 = new PageAsyncTask(
new BeginEventHandler(BeginAsyncOperation1),
new EndEventHandler(EndAsyncOperation1),
new EndEventHandler(TimeoutAsyncOperation1),
null
);
RegisterAsyncTask(task);
RegisterAsyncTask(task1);
}
}
如果在页面属性AsyncTimeout的规定时间内得到异步任务返回的结果，那么页面将按照我们预期的显示。但是如果在执行第一个任务时遇到了小麻烦，耽误了时间会怎么样呢？有两种可能：一是，第一个任务的结果最终返回并显示出来，而第二个任务刚一启动就被判定为超时，从而执行了它的TimeoutAsyncOperation方法；二是，第一个任务没有等到返回结果就已被判超时，因此第二个任务也一定被判超时了。以上情况是由于两个异步任务分享了AsyncTimeout规定的时间，只要前面那个任务在执行时耽误了时间，必然影响到后面那个任务的运行。那么能不能让两个异步任务独享AsyncTimeout规定的时间呢，这就要在ExecuteRegisteredAsyncTasks方法上找出路了。
值得注意的是，每次调用ExecuteRegisteredAsyncTasks时，Asp.net2.0都将重置AsyncTimeout属性，这意味着有可能实现异步任务独享AsyncTimeout规定的时间。按照目前程序的写法，如果不显示调用ExecuteRegisteredAsyncTasks方法，Asp.net2.0会在页面生命周期中的PreRenderComplete
事件之前自动调用ExecuteRegisteredAsyncTasks方法来运行这两个注册的异步任务。因为只执行了一次ExecuteRegisteredAsyncTasks却运行了两个任务，那么这两个任务便只好分享AsyncTimeout规定的运行时间了。于是我对代码做了如下调整：
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
PageAsyncTask task = new PageAsyncTask(
new BeginEventHandler(BeginAsyncOperation),
new EndEventHandler(EndAsyncOperation),
new EndEventHandler(TimeoutAsyncOperation),
null
);
PageAsyncTask task1 = new PageAsyncTask(
new BeginEventHandler(BeginAsyncOperation1),
new EndEventHandler(EndAsyncOperation1),
new EndEventHandler(TimeoutAsyncOperation1),
null
);
RegisterAsyncTask(task);
ExecuteRegisteredAsyncTasks();
RegisterAsyncTask(task1);
ExecuteRegisteredAsyncTasks();
}
}
乍一看似乎有点问题：第二个ExecuteRegisteredAsyncTasks方法会不会将注册的第一个异步任务又执行一次？其实不会的，因为Asp.net2.0已经规定同一个异步方法只会执行一次。因此这样就使两个异步任务独享了运行时间，避免了互相干扰。但是这样做使两次异步操作提前到Page_Load事件处理过程中进行，导致当前线程被连续两次放入线程池中准备为其他请求服务，目前我还不知道这样做会不会有什么不利的影响。