连接字符串生成器简介

此代码仍然生成相同的连接字符串，但此代码的编写更容易一些。另外，如果在提供连接字符串关键字时产生了输入错误，将会产生一个编译时错误。如果正在Microsoft Visual Studio中编写代码，并且难以记住连接字符串选项，那么可以很容易地通过IntelliSense下拉菜单使用SqlConnectionStringBuilder中的可用选项。使用这些下拉菜单还可以减少输入字符，防止出现一些输入错误，在其他情况下，需要到测试代码时才能发现这些错误。

3. 处理复杂的连接字符串选项值

使用连接字符串生成器的一个间接好处是：不必再记忆如何分析、转义或分隔连接字符串中的值。假定需要提供一个包括空格的连接字符串值，是否需要在关键字两侧加引号呢？用大括号？一个也不用？还是用两个？

如果以手动方式生成连接字符串，那么这些问题不存在简单的答案。事实上，其答案取决于所使用的.NET数据提供程序。过去使用过ODBC的开发人员可能还会记得：包含空间的ODBC驱动程序名称必须用大括号分隔："Driver={SQL Server}"。利用连接字符串生成器来代替手动方式生成连接字符串，就不再为这些问题而费心。

如果正在使用连接字符串生成器，可以将逻辑交给生成器处理。例如，可能希望使用连接字符串选项以连接到服务器，并在过程中附加一个数据库文件。希望使用的文件可能在路径中包含空格或其他字符。开发人员不必担心是否或如何分隔连接字符串中的文件名称，只需要使用SqlConnectionStringBuilder类来生成连接字符串，如下所示：

SqlConnectionStringBuilder bldr = new SqlConnectionStringBuilder();

bldr.DataSource = @".\SQLExpress";

bldr.IntegratedSecurity = true;

bldr.AttachDBFilename = @"C:\My Complex Path\AttachMe.mdf";

//将生成的连接字符串输出到控制台窗口

Console.WriteLine("Resulting connection string: {0}", bldr.ConnectionString);

//以SqlConnection使用所生成的连接字符串

SqlConnection cn = new SqlConnection(bldr.ConnectionString);

cn.Open();

读者可能出于某种原因而希望了解如何正确分隔连接字符串中的文件名称，那么该代码段生成以下连接字符串：

Data Source=.\SQLExpress;AttachDbFilename="C:\My Complex Path\AttachMe.mdf";

Integrated Security=True

4. 恶意连接字符串输入，也称为“连接字符串注入”

在编写安全代码时，最重要的规则之一就是“绝对不要盲目相信用户输入”。参数化查询(这一主题将在第4章中详细讨论)非常有用，其原因有很多，但重要原因之一是它可以防止SQL注入。可以构建一个参数化查询，并为参数指定由用户提供的取值，而不必担心用户输入是否会改变查询的结构。在生成连接字符串时也存在类似问题。

您可能决定对用户进行提示，使其输入凭据——提供一个文本框以允许用户输入用户名和密码，然后利用以下代码，基于连接字符串中的输入来构造连接字符串。

string strConn;

strConn = @"Data Source=.\SQLExpress;Initial Catalog=Northwind;" +

              "User ID=" + txtUserID.Text + ";" +

              "Password=" + txtPassword.Text + ";"

Console.WriteLine("Resulting connection string: {0}", strConn);

乍看起来，这似乎是安全而符合逻辑的。现在假定有一位恶意用户，他希望修改此连接字符串。图3.1说明了一种方式，这种恶意用户可以采用这种方式来修改要访问哪个服务器。由于没有更好的术语，我们将这种方法称为“连接字符串注入”。

图3.1   恶意用户尝试通过用户输入改变应用程序访问的服务器

利用以上代码段和如图3.1所示的输入，所得到的连接字符串如下所示：

Data Source=.\SQLExpress;Initial Catalog=Northwind;User ID=MyUserID;

Data Source=EvilServerName;Password=MyPassword;

可以看到，Data Source被指明两次。在使用所得到的连接字符串时，会选用哪个值呢？是第一个(本地计算机)，还是第二个(“evil”服务器)？是否存在手动检查用户输入的方式，以检查诸如此类的可能的连接字符串注入？这些答案对于其他连接字符串关键字或其他.NET数据提供程序是否正确呢？开发人员能够做些什么呢？

幸运的是，连接字符串生成器可以帮助开发人员处理来自恶意或恶作剧用户的输入。

5. 用连接字符串生成器防止连接字符串注入

利用SqlConnectionStringBuilder重新编写前面的代码段，得到以下代码：

<connectionStrings>     <add name="DatabaseConnection"          connectionString="Persist Security Info=False;Integrated Security=SSPI;database=Northwind;server=(local);"          providerName="System.Data.SqlClient" /> </connectionStrings> 

从配置文件中检索连接字符串

System.Configuration 命名空间提供使用配置文件中存储的配置信息的类。ConnectionStringSettings 类具有两个属性，映射到上面所示的 <connectionStrings> 示例部分中显示的名称。

ConnectionString

连接字符串。

Name

<connectionStrings> 部分的连接字符串的名称。

安全注意
可以使用受保护的配置可选地加密配置文件中存储的连接字符串。请参见使用受保护的配置加密配置信息、对配置节进行加密和解密和演练：使用受保护的配置加密配置信息。

示例