考虑以下(并非不现实的)场景。这是一个正常的工作日早晨,您的异常监控突然开始发送大量 SQL 登录错误。在给您的基础架构团队打了几次惊慌失措的电话后,很明显数据库服务器上的 RAID 控制器出现故障。最近的替代品在另一个国家/地区,至少需要 48 小时才能到达。
幸运的是,您的 DBA 已经准备好并已开始在另一台服务器上进行恢复,该服务器将在不到一个小时内可用,其中一位将很快给您打电话告知连接详细信息。
此时,如果您的应用程序将数据库连接详细信息存储在一个中央位置,您应该能够在备份数据库恢复后几乎立即使应用程序重新联机 - 在快速测试以确保没有发生数据损坏和正常功能之后可用。
如果您必须搜索项目中的每一个页面和类,那么更新所有不同的连接字符串可能需要几个小时,而且您不能确定您没有错过任何一个。
与其在午餐前恢复应用程序,不如让用户一直工作到深夜,因为用户对你失去了一天感到愤怒。
诚然,查找/替换工具将使跟踪对服务器/数据库名称的引用变得更加容易,而无需手动搜索每一行代码,但是您仍然使生活变得比需要的困难得多。
微软在 web.config 文件中创建了连接字符串元素是有充分理由的,它可以满足许多高安全性环境,甚至为字符串提供加密以保证它们的安全。简而言之,使用ReSharper、dotPeek或JustDecompile 之类的解决方案,即使是编译后的代码也几乎可以立即变得可读。如果您的经理认为在编译后的代码中保留连接字符串更安全,那么他们就错了。
如果您必须将连接字符串存储在 web.config 之外,那么我建议您为此目的创建一个实用程序类 -
using System;
namespace YourApplicationNameSpace
{
public static class Common
{
public static string DatabaseConnectionString
{
get { return "server=myserver;database=Products;uid=salesUser;pwd=sellMoreProducts"; }
}
}
}
然后可以将字符串添加到页面的声明性数据源中,如下所示 -
<asp:SqlDataSource ID="DataSource" runat="server" ProviderName="Oracle.DataAccess.Client"
SelectCommand="SELECT * from aTable"></asp:SqlDataSource>
在后面的代码中 -
protected void Page_Load(object sender, EventArgs e)
{
DataSource.ConnectionString = YourApplicationNameSpace.Common.DatabaseConnectionString;
}
这看起来像贵公司使用的模式。
我相信这也可以(注意添加等号)-
<asp:SqlDataSource ID="DataSource" runat="server"
ConnectionString='<%= MyNameSpace.Credentials.Instance.DatabaseConnectionString %>'
ProviderName="Oracle.DataAccess.Client"
SelectCommand="SELECT * from aTable">
</asp:SqlDataSource>
如果您必须将连接字符串限制在单个页面中,那么-
protected void Page_Load(object sender, EventArgs e)
{
DataSource.ConnectionString = "server=myserver;database=Products;uid=salesUser;pwd=sellMoreProducts";
}
然后开始寻找新工作,因为维护代码将是一场噩梦。
旁注,您应该确保为 SQL 使用参数化命令,尤其是在更新或删除数据以避免SQL 注入- 甚至更好的存储过程(也使用正确构造的参数)时。