次の(非現実的ではない)シナリオを考えてみましょう。例外監視が突然多数のSQLログオンエラーの送信を開始するのは、通常の平日の朝です。インフラストラクチャチームに数回パニック状態で電話をかけた後、データベースサーバーのRAIDコントローラーに障害が発生したことが明らかになりました。最寄りの代替品は別の国にあり、到着するまでに少なくとも48時間かかります。
幸いなことに、DBAは順調に進んでおり、1時間以内に利用できる別のサーバーへの復元を開始しました。そのうちの1つは、まもなく接続の詳細を電話で通知するためです。
この時点で、アプリケーションがデータベース接続の詳細を単一の中央の場所に保存している場合、バックアップデータベースが復元されるとすぐに、アプリケーションをオンラインに戻すことができるはずです-データの破損が発生していないことと通常の機能を確認するための迅速なテストの後利用可能です。
プロジェクト内のすべてのページとクラスを検索する必要がある場合、すべての異なる接続文字列を更新するのに数時間かかる可能性があり、1つを見逃していないことを確認することはできません。
昼食前にアプリケーションを復元する代わりに、あなたは夜遅くまでうまく働いており、ユーザーは失われた日にあなたに腹を立てています。
確かに、検索/置換ツールを使用すると、コードのすべての行を手動で検索しなくても、サーバー/データベース名への参照を簡単に追跡できますが、それでも必要以上に困難になります。
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インジェクションを回避するためにデータを更新または削除する場合、またはさらに優れたストアドプロシージャ(適切に構築されたパラメータを使用)を使用する場合は、SQLにパラメータ化されたコマンドを使用していることを確認する必要があります。