我正在修改一些有人编写的旧代码,他们在web.config中放置了一个连接字符串,由于业务规则,我不得不将其删除。我创建了一个生成连接字符串的单例类,并希望以类似的方式在asp.net标记中设置它:
<asp:SqlDataSource ID="DataSource" runat="server"
ConnectionString='<% MyNameSpace.Credentials.Instance.DatabaseConnectionString %>'
ProviderName="Oracle.DataAccess.Client"
SelectCommand="SELECT * from aTable">
</asp:SqlDataSource>
不幸的是,这不起作用,并且正在使用该行并将其用作文字连接字符串。有人知道如何像这样访问内联类的属性吗?
答案 0 :(得分:1)
考虑以下(不是不现实的)场景。这是正常的工作日早晨,当您的异常监控突然开始发送大量SQL登录错误时。在对您的基础架构团队进行几次惊慌的电话呼叫后,很明显数据库服务器上的RAID控制器出现故障。最近的替代品在另一个国家/地区,至少需要48小时才能到达。
幸运的是,您的DBA已经开始并且已经开始恢复到另一台服务器上,该服务器将在不到一个小时内完成,其中一个服务器将很快通过电话向您发送连接详细信息。
此时,如果您的应用程序将数据库连接详细信息存储在单个中心位置,则应该能够在备份数据库恢复后立即将应用程序重新联机 - 快速测试后确保没有发生数据损坏并且可以使用正常功能。
如果您必须搜索项目中的每个页面和类,那么更新所有不同的连接字符串可能需要数小时,而您无法确定是否错过了一个。
而不是在午餐前恢复应用程序,你工作得很好,因为用户对你失去了一天的生气。
不可否认,查找/替换工具可以更轻松地跟踪对服务器/数据库名称的引用,而无需手动搜索每行代码,但您仍然需要比以前更难的生活。
Microsoft出于充分的理由在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使用parameterized commands,尤其是在更新或删除数据时为了避免SQL injection - 或者甚至更好的存储过程(也使用正确构造的参数)