在程序中要存储connection strings,我们有不少的选择的。每一种方法都有自己的优缺点,特别是在灵活性和安全性上。当然,很多人就直接把connection strings写在了程序里,这样虽然效率提高了一些,可是实在是非常不方便将来的修改和配置,所以并不是一种推荐的行为。

在选择connection strings存储方式时,感觉最重要的是安全性和易配置性,其次就是性能。在各类资料中,我们可以看到,存储的方式主要有:
1)程序配置文件,例如asp.net中的web.config文件
2)windows注册表中
3)UDL文件
4)在COM+的catalog中(只用于serviced component)

下面,我们逐个来讨论一下这几种方法的优缺点:

1)使用XML程序配置文件
我们可以使用来把 connection string存储在程序配置文件的custom settings部分。
<configuration>
<appSettings>
<add key="DBConnStr"
value="server=(local);Integrated Security=SSPI;database=northwind"/>
</appSettings>
</configuration>

优点:
a)很明显,容易分发。connection string可以跟随.NET的xcopy机制极其简单的deploy。
b)易编程性。我们可以使用 ConfigurationSettings 中的AppSetting来读取connection string
using System.Configuration;
private string GetDBaseConnectionString()
{
return ConfigurationSettings.AppSettings["DBConnStr"];
}
c)在ASP.NET中使用的话,可以自动更新。也就是说,如果一个管理员修改了web.config中的connection string,下一次这个string被访问是,修改后的内容会被使用。这点在web编程中非常实用。
缺点:
安全性:虽然ASP.NET中已经明确写了带.config后缀的文件是不能被客户访问的,并且NTFS文件系统可以用来进一步加强安区性,在web server中用明文来存储connection string还是让人觉得不爽啊。幸运的是,MS还提供了在配置文件中用encrypted方式存储的办法,这下基本上就OK乐。

2)使用UDL文件
OLE DB .NET Data Provider支持在connection string中使用UDL文件。具体方法可以参考KB Q308426 "HOW TO: Use Data Link Files with the OleDbConnection Object in Visual C# .NET"。这种方法不能用于SQL Server .NET Data Provider.

优点:
这也是一种比较标准的方法,特别是你以前就用UDL。
缺点:
a) 性能。 每次connection打开时都需要去读取和分析UDL文件。
b) 安全性。UDL文件是以明文的方式存放的,我们只能通过NT的文件系统设置它的访问权限。
我们要注意在ASP.NET中,要保证ASP.NET跑的账号有读的权限。并且,注意不要把UDL文件放在虚拟目录中,不然它有可能会被客户下载。

3)使用注册表
当然我们也可以在注册表中增加一个键来存储connection,但是这样比较难以分发。

优点:
a) 安全性. 我们可以对注册表的键使用ACL来控制读写权限,也可以考虑加密信息。
b) 易编程性。.NET也提供了很多类使我们可以容易的操作注册表。
缺点:
分发。 这种方式必须要把相应注册表的修改也放入程序的分发过程中,一定程度上与.NET的xcopy不相符合了。

4)使用自定义文件
我们当然也可以自定义一种文件格式来储存connection string.但是这样的话就没有太多优点了,而且需要额外的编程,并且不容易分发,所以在很多场合下不太适用。

5)使用COM+的catalog和construction arguments
在使用到COM+的时候,我们也会把connection string存到COM+的catalog中,然后通过object construction string来传递给object。COM+会在初始化对象时调用对象的construct函数,这种方法只适用于service components.当我们用到分布式transaction或object pooling时,我们就可以考虑这种方法。

优点:
管理:Admin可以非常容易的使用MMC配置connection string.
缺点:
安全性:虽然我们可以控制COM+中的role, COM+ catalog 不是一个非常安全的存储地区,所以不要以明文的形式在其中存储connection string。
分发性:COM+ catalog中的内容也必须和我们的程序一起分发。这部分的内容比较多,这里我就不一一详述了。