开发笔记 第788页

概述

HttpApplication对象对于做ASP.NET开发的朋友，我想没有人不熟悉它。在ASP.NET开发中，经 常避免不了要在HttpApplication中执行一些操作，如使用了ASP.NET MVC框架，就会在Application_Start 事件中避免不了这样的路由规则配置代码：

protected void Application_Start()
{
RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
RouteTable.Routes.MapRoute(
"Default",                                              // Route name
"{controller}/{action}/{id}",                           // URL with parameters
new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
);
}

如果仅仅是这一条，看起来倒不觉的有什么问题，但如果同时在应用程序中使用了工作流，又避免不了在Application_Start出现启动工作流运行时的代码：

protected void Application_Start()
{
// 注册路由规则
RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
RouteTable.Routes.MapRoute(
"Default",                                              // Route name
"{controller}/{action}/{id}",                           // URL with parameters
new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
);
// 启动工作流
WorkflowRuntime workflowRuntime = new WorkflowRuntime("workflowServicesConfig");
ExternalDataExchangeService externalDataExchangeService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalDataExchangeService);
workflowRuntime.StartRuntime();
}

试想一下，现在我们仅仅是有了ASP.NET MVC路由规则的配置、WF运行时的启动，如果在应用程序中使用某种DI框架，如微软的Unity，是不是又避免不了要出现这样的容器初始化代码呢？

protected void Application_Start()
{
// 注册路由规则
RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
RouteTable.Routes.MapRoute(
"Default",                                              // Route name
"{controller}/{action}/{id}",                           // URL with parameters
new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
);
// 启动工作流
WorkflowRuntime workflowRuntime = new WorkflowRuntime("workflowServicesConfig");
ExternalDataExchangeService externalDataExchangeService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalDataExchangeService);
workflowRuntime.StartRuntime();
// 初始化DI容器
IContainerContext repositoryContainer = ContainerManager.GetContainer("repositoryContainer");
repositoryContainer.Initialize();
}

再看看Application_Start事件中的代码，有ASP.NET MVC的工作，有WF的工作，也有Unity的工作，不知道将来还会有什么？这些原本互相之间没有任何联系的代码，现在却同时堆在了一起，当每一部分（或 者说每一个框架）变化的时候，都会涉及到Application_Start中代码的修改，显然违反了OCP原则。那么有没有一种机制，让这些互不相干的 模块之间互相独立，各自发生变化时不影响对HttpApplication？此时我们就需要对HttpApplication进行扩展，提供一个扩展点， 让其他模块的程序附加到HttpApplication上面。

可扩展对象模式

我们知道WCF提供了非常完美的扩展机制，几乎在服务执行过程中的每一个环节上都提供有扩展点，如ServiceHostBase、 OperationContext、InstanceContext、IContextChannel，这些对象都属于可扩展对象，它们都通过 Extensions属性获取用于所有扩展的集合。我们能不能使用这种方式对HttpApplication也进行扩展呢，答案自然是肯定的。查阅一下 MSDN就会知道在System.ServiceModel命名空间下面提供了这样的一组接口：IExtensibleObject、 IExtension和IExtensionCollection，这是可扩展对象模式中最重要的三个接口，也只有这三个接口。

IExtensibleObject自然是定义了可扩展对象，即我们要对谁进行扩展，它的定义非常简单，仅仅是提供了一个只读的属性Extensions，用来提供所有扩展对象的集合，如下代码所示：

public interface IExtensibleObject<T> where T : IExtensibleObject<T>
{
IExtensionCollection<T> Extensions { get; }
}

IExtension定义了扩展对象的契约，使对象可以通过聚合扩展另一个对象（此处的另一个对象，就是指上面所讲的扩展宿主 IExtensibleObject），在IExtension中定义了两个非常重要的方法Attach和Detach方法，分别用来提供聚合或解聚的通 知。

public interface IExtension<T> where T : IExtensibleObject<T>
{
void Attach(T owner);
void Detach(T owner);
}

当一个扩展对象IExtension附加到可扩展对象的扩展集合中时，它的Attach方法将会被调用；反之如果从集合中移除一个扩展对象时，它的Detach方法会被调用。这一点我们可以通过Reflector来得到验证，如下代码所示：

protected override void InsertItem(int index, IExtension<T> item)
{
lock (base.SyncRoot)
{
item.Attach(this.owner);
base.InsertItem(index, item);
}
}
protected override void RemoveItem(int index)
{
lock (base.SyncRoot)
{
base.Items[index].Detach(this.owner);
base.RemoveItem(index);
}
}

最后一个接口是IExtensionCollection，它是IExtension对象的集合。

对HttpApplication进行扩展

下面我们就看一下如何使用可扩展对象模式对HttpApplication进行扩展，首先定义可扩展对象，让 ExtensibleHttpApplication派生于HttpApplication，并实现了IExtensibleObject接口，泛型的参 数类型就是它自身，如下代码所示：

public class ExtensibleHttpApplication : HttpApplication,
IExtensibleObject<ExtensibleHttpApplication>
{
private IExtensionCollection<ExtensibleHttpApplication> _extensions;
public ExtensibleHttpApplication()
{
this._extensions = new ExtensionCollection<ExtensibleHttpApplication>(this);
}
public IExtensionCollection<ExtensibleHttpApplication> Extensions
{
get
{
return this._extensions;
}
}
}

有了可扩展的HttpApplication之后，需要在HttpApplication中实现任何功能，都可以作为一个扩展附加到ExtensibleHttpApplication上去，如实现ASP.NET MVC路由，可以定义一个如下代码所示的扩展对象：

public class MvcHttpApplication : IExtension<ExtensibleHttpApplication>
{
public void Attach(ExtensibleHttpApplication owner)
{
RouteTable.Routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
RouteTable.Routes.MapRoute(
"Default",                                              // Route name
"{controller}/{action}/{id}",                           // URL with parameters
new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
);
}
public void Detach(ExtensibleHttpApplication owner)
{
//nothing
}
}

同样如果要在HttpApplication中启动Workflow，可以再针对Workflow定义一个扩展对象，如下示例代码所示：

public class WorkflowHttpApplication : IExtension<ExtensibleHttpApplication>
{
private WorkflowRuntime workflowRuntime;
public void Attach(ExtensibleHttpApplication owner)
{
workflowRuntime = new WorkflowRuntime("workflowServicesConfig");
ExternalDataExchangeService externalDataExchangeService = new ExternalDataExchangeService();
workflowRuntime.AddService(externalDataExchangeService);
workflowRuntime.StartRuntime();
}
public void Detach(ExtensibleHttpApplication owner)
{
workflowRuntime.StopRuntime();
}
}

我们已经定义好了相应的扩展对象，只需要在相应的HttpApplication把扩展对象附加到ExtensibleHttpApplication上即可，修改Global.asax中的代码如下所示：

public class MvcApplication : ExtensibleHttpApplication
{
protected void Application_Start()
{
this.Extensions.Add(new MvcHttpApplication());
this.Extensions.Add(new WorkflowHttpApplication());
}
}

现在代码是不是看起来优雅多了？现在如果要在Application_Start中，添加另外一些执行代码，只需要编写相应的扩展对象，并将其添加 到Extension集合中即可。也许有朋友会问，这样每添加一些新的代码，还是要修改Application_Start中的代码啊？别忘了，可以通过 配置可以解决这个问题，WCF中的扩展不也是可以采用配置方式实现，不是吗？同样，如果我们需要在Application_End事件中释放某些对象，可 以直接从扩展集合中移除它，此时将会调用它的Detach方法。

总结

本文介绍了如何使用WCF中提供的可扩展对象模式扩展HttpApplication，事实上可扩展对象模式的作用远不在此，它可以扩展.NET类库中任何我们想对其进行扩展的对象，或者是一个自定义的类型，都可以使用可扩展对象模式对其进行扩展。

特别鸣谢：Jesse Qu

注1：由于TerryLee最近一段时间忙于别的事务，无暇顾及Blog，所以有大量的评论和E-mail都没能回复，请大家见谅。

注2：由TerryLee撰写的《Silverlight 2完美征程》一书，即将于本月底上市，敬请期待，详情大家可以访问本书官方网站http://www.dotneteye.cn/silverlight了解。

我们经常出于某种目的需要使用各种各样的日期格式，当然我们可以使用字符串操作来构造各种日期格式,但是有现成的函数为什么不用呢？
SQL Server中文版的默认的日期字段datetime格式是yyyy-mm-dd Thh:mm:ss.mmm
例如:
select getdate()
2004-09-12 11:06:08.177
整理了一下SQL Server里面可能经常会用到的日期格式转换方法:
举例如下:
select CONVERT(varchar, getdate(), 120 )
2004-09-12 11:06:08
select replace(replace(replace(CONVERT(varchar, getdate(), 120 ),'-',''),' ',''),':','')
20040912110608
select CONVERT(varchar(12) , getdate(), 111 )
2004/09/12
select CONVERT(varchar(12) , getdate(), 112 )
20040912
select CONVERT(varchar(12) , getdate(), 102 )
2004.09.12
select CONVERT(varchar(12) , getdate(), 101 )
09/12/2004
select CONVERT(varchar(12) , getdate(), 103 )
12/09/2004
select CONVERT(varchar(12) , getdate(), 104 )
12.09.2004
select CONVERT(varchar(12) , getdate(), 105 )
12-09-2004
select CONVERT(varchar(12) , getdate(), 106 )
12 09 2004
select CONVERT(varchar(12) , getdate(), 107 )
09 12, 2004
select CONVERT(varchar(12) , getdate(), 108 )
11:06:08
select CONVERT(varchar(12) , getdate(), 109 )
09 12 2004 1
select CONVERT(varchar(12) , getdate(), 110 )
09-12-2004
select CONVERT(varchar(12) , getdate(), 113 )
12 09 2004 1
select CONVERT(varchar(12) , getdate(), 114 )
11:06:08.177
帮助文档中的信息

1.       连接法——结合字体特征将笔画相连接的形式


2.       简化法——根据字体特点，利用视觉错觉合理地简化字体部分笔画的形式

3.       附加法——在字体外添加配合表现标示的图形的形式


4.       底图法——将字体镶嵌于色块或图案中的形式

5.       象征法——将字体的笔画进行象征性演变的形式

6.       柔美法——结合字体特征，运用波浪或卷曲的线条来表现的形式


7.       刚直法——用直线型的笔画来组成字体的形式

8.       印章法——以中国传统印章为底纹或元素的形式

9.       书法法——把中国书法融入字体设计中的形式


10.   综合元素——综合使用各种风格来修饰标志的形式

初步分析原因为对MSSQL操作时连接超时，知道这事，以前没留意，大概是在配置文件中设置连接时限，在网上找了下解决方法，大多说在数据库连接字符串里解决

SQLConnection con = new SqlConnection("server=.;database=myDB;uid=sa;pwd=password;")

改为：

SqlConnection con = new SqlConnection("server=.;database=myDB;uid=sa;pwd=password;Connect Timeout=500")

似乎没效果。依然运行30秒即报超时！
突然感觉似乎应该可以在连接数据库代码中指明，式了下con的属性，有个ConnectionTimeout，

SqlConnection con = new SqlConnection("server=.;database=myDB;uid=sa;pwd=;");
con.ConnectionTimeout = 180;//报错，属性ConnectionTimeout 为只读！

尝试失败，再接着看command对象属性，发现其也有类似属性！CommandTimeout设置一下：

SqlCommand cmd = new SqlCommand();
cmd.CommandTimeout = 180;

再运行，即解决，这里设置的时间的180秒，即三分钟！可根据需要设置，如果过长，也可以设置为0，当此属性设置为0时表示不限制时间。此属性值应该慎用。还需要在Web.config配置文件中设置http请求运行时限间

<system.web>  
<httpRuntime maxRequestLength="102400" executionTimeout="720" />
</system.web>

这里设置的为720秒，前面的属性maxRequestLength一般用于用户上传文件限制大小！默认一般为4096 KB (4 MB)。
看一下来自MSDN解释：
     httpRuntime是配置ASP.NET http运行时设置，以确定如何处理对ASP.NET应用程序的请求。
     executionTimeout:表示允许执行请求的最大时间限制，单位为秒
     maxRequestLength：指示 ASP.NET 支持的最大文件上载大小。该限制可用于防止因用户将大量文件传递到该服务器而导致的拒绝服务攻击。指定的大小以 KB 为单位。默认值为 4096 KB (4 MB)。
     useFullyQualifiedRedirectUrl：表示指示客户端重定向是否是完全限定的（采用 "http://server/path" 格式，这是某些移动控件所必需的），或者指示是否代之以将相对重定向发送到客户端。如果为 True，则所有不是完全限定的重定向都将自动转换为完全限定的格式。false 是默认选项。
     minFreeThreads：表示指定允许执行新请求的自由线程的最小数目。ASP.NET 为要求附加线程来完成其处理的请求而使指定数目的线程保持自由状态。默认值为 8。
    minLocalRequestFreeThreads：表示ASP.NET 保持的允许执行新本地请求的自由线程的最小数目。该线程数目是为从本地主机传入的请求而保留的，以防某些请求在其处理期间发出对本地主机的子请求。这避免 了可能的因递归重新进入 Web 服务器而导致的死锁。
    appRequestQueueLimit：表示ASP.NET 将为应用程序排队的请求的最大数目。当没有足够的自由线程来处理请求时，将对请求进行排队。当队列超出了该设置中指定的限制时，将通过“503 – 服务器太忙”错误信息拒绝传入的请求。
    enableVersionHeader：表示指定 ASP.NET 是否应输出版本标头。Microsoft Visual Studio 2005 使用该属性来确定当前使用的 ASP.NET 版本。对于生产环境，该属性不是必需的，可以禁用。

MSDN:MSND官方解释说明

下面列出了几个比较常见的开源协议，如果想要了解其他的协议和详细了解这些协议，我个人推荐这个网址：http://www.opensource.org/licenses/

Mozilla Public License

MPL License，允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。这种授权维护了商业软件的利益，，它要求基于这种软件得修改无偿贡献 版权给该软件。这样，围绕该软件得所有代码得版权都集中在发起开发人得手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。

BSD开源协议

BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2． 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因 此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次 开发。

Apache Licence 2.0

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件：
1． 需要给代码的用户一份Apache Licence
2． 如果你修改了代码，需要再被修改的文件中说明。
3． 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4． 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

GPL

GPL许可证是自由软件的应用最广泛的软件许可证，人们可以修改程式的一个或几个副本或程式的任何部分，以此形成基於这些程式的衍生作品。必须在修 改过的档案中附有明显的说明：您修改了此一档案及任何修改的日期。您必须让您发布或出版的作品，包括本程式的全部或一部分，或内含本程式的全部或部分所衍 生的作品，允许第三方在此许可证条款下使用，并且不得因为此项授权行为而收费。
LGPL

Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代 码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商 业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既 必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似

Public Domain

公共域授权。将软件授权为公共域，这些软件包没有授权协议，任何人都可以随意使用它。

Artistic许可

使作者保持对进一步开发的控制。