在程序中要存储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中的内容也必须和我们的程序一起分发。这部分的内容比较多，这里我就不一一详述了。