.net - .NET / LINQ-SQL / ASP.NET の接続文字列地獄

Question

以下を含む Web アプリケーションがあります。

Web プロジェクト (接続文字列を含む web.config ファイルを使用しますが、Web プロジェクトにデータアクセスコードは含まれません)
LINQ-SQL クラスを使用して Web プロジェクト UI にエンティティを提供するデータアクセスプロジェクト (このプロジェクトには設定ファイルと app.config があり、どちらにも接続文字列があります)

ビルドしてデプロイすると、Bin ディレクトリにデータアクセス .dll を含む設定ファイルまたは app.config がありませんが、web.config ファイルの接続文字列を変更してもそれに応じてデータベースが変更されないため、接続文字列はデータアクセス dll にコンパイルされます。

必要なのは、デプロイ全体 (Web サイト、データアクセス dll、すべて) に対して 1 つの構成ファイルであり、使用される接続文字列が 1 つあります。現時点では、複数の接続文字列があちこちで使用またはハードコーディングされているようです。

この混乱をどのように解決するのが最善でしょうか?

助けてくれてありがとう。

score 14 · Accepted Answer

ファイルの接続文字列を使用できるデータアクセスレイヤー(DAL) で問題が発生したことはありませんweb.config。通常、DAL から接続文字列セクションをコピーして、web.config. DBML デザイナーを使用してデータコンテキストを作成しています。

これがうまくいかない場合は、データコンテキストコンストラクターで接続文字列を指定できます。Web プロジェクトには、接続文字列を含む設定をロードする静的クラスがあり、DAL オブジェクト (直接作成する場合はデータコンテキスト) を作成するときに、それをコンストラクターに渡すだけです。

public static class GlobalSettings
{
    private static string dalConnectionString;
    public static string DALConnectionString
    {
       get
       {
           if (dalConnectionString == null)
           {
              dalConnectionString = WebConfigurationManager
                                      .ConnectionStrings["DALConnectionString"]
                                        .ConnectionString;
           }
           return dalConnectionString;
       }
    }
}
...

using (var context = new DALDataContext(GlobalSettings.DALConnectionString))
{
   ...
}

score 6 · Accepted Answer

スタートアッププロジェクトの構成ファイルは、含まれるすべてのプロジェクトの構成設定を定義します。たとえば、Web プロジェクトがスタートアッププロジェクトの場合、"appSettings" への参照は web.config からの設定を検索します。これには、データアクセスプロジェクトからの "appSettings" への参照が含まれます。そのため、構成設定をデータアクセスプロジェクトの app.config から Web プロジェクトの web.config にコピーします。

score 5 · Accepted Answer

レジストリに基づいて独自の ConnectionFactory をロールします。

SOFTWARE/[YOUR_COMPANY]/[YOUR_APP] の下にアプリケーションのレジストリキーを追加します。
ConnectionString の文字列値を追加します
ConnectionFactory に適切なレジストリキーを解読するように教えます (すべてのページの読み込みではなく、静的コンストラクターで!)。
レジストリ情報を .reg ファイルとしてエクスポートし、ソース管理に追加し、必要に応じて変更して適用し、追加のマシンをセットアップします。

プロ：

セットアップが簡単
接続文字列は 1 つの場所に存在します
web/app.config にはないため、環境固有の設定をハードコーディングする必要はありません。
web/app.config にはないため、Junior Dev Jimmy が誤って実稼働サーバーに DEV データベースを参照するように指示することはありません

短所：

重要なものがレジストリに存在することはすぐには明らかではないため、新しい開発者は指示が必要になります。
新しい展開マシンを構成するときの追加の手順
レジストリは oldskool です。ジュニア開発者はあなたを嘲笑します。

score 4 · Accepted Answer

回答ありがとうございます。

アプリが web.config の設定を使用すると言う人は、私が自分のコードでそれを参照する場合には正しいです。

_connectionString = ConfigurationManager.AppSettings["ConnectionString"];

..しかし、LINQ-SQL データコンテキストには別の問題があります。パラメーターなしのコンストラクターで使用するために、コンパイルされた dll に接続文字列が含まれていると思います。tvanofosson が言うように、web.config で接続文字列への参照を渡すことによって、datacontexts を作成する必要があります。これは私がもつれに陥っていた場所です:)

score 3 · Accepted Answer

私もこの問題に少し苦労しました。C# の部分クラス定義を使用し、dbml デザイナーによって作成された datacontext を拡張することで解決策を見つけました。この解決策は、tvanfossonの答えに非常に似ています。あなたがしなければならないことは、設定からConnectionStringを取得するデフォルトのコンストラクターで部分的なデータコンテキストクラスを作成し、dbmlデザイナーDCプロパティで接続をNoneに設定することです。そうすれば、接続文字列はdllにコンパイルされません。Datacontext は、web.config 接続文字列設定から接続文字列を自動的に取得します。これが app.config でも機能するかどうかはテストしていませんが、うまく機能すると思います。

部分的な DC クラスのサンプルを次に示します。

namespace MyApplication {
    /// <summary>
    /// Summary description for MyDataContext
    /// </summary>
    /// 
    public partial class MyDataContext
    {
        public MyDataContext() :
            base(global::System.Configuration.ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString, mappingSource)
        {
            OnCreated();
        }
    }
}

score 3 · Accepted Answer

アプリケーションは、web.config ファイル内の構成エントリのみを使用します。適切な構造である限り、web.config ファイルに dll 構成設定を入れることができます。私の例は、My Namespace を使用した VB 固有のものですが、一般的な考え方を示しています。

構成ファイルの configSections パレットには、次のエントリが必要です。

<configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
        <section name="YourAssembly.My.MySettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    </sectionGroup></configSections>

次に、構成ファイルの applicationSettings 部分に、各 dll のエントリを配置します。

    <applicationSettings>
      <YourAssembly.My.MySettings>
        <setting name="DebugMode" serializeAs="String">
            <value>False</value>
        </setting>
      </YourAssembly.My.MySettings>
    </applicationSettings>

score 2 · Accepted Answer

自動生成されたコードから安全に保つには、データコンテキストの OnCreated() メソッドで接続情報をオーバーライドします。

using System.Configuration;
namespace MyApplication 
{
    partial void OnCreated()
    {
        // attempt to use named connection string from the calling config file
        var conn = ConfigurationManager.ConnectionStrings["MyConnectionString"];
        if (conn != null) Connection.ConnectionString = conn.ConnectionString;
    }
}

このように、dbml デザイナーは独自の方法で接続を行うことができますが (これは Web プロジェクト以外では適切ではありません)、アプリケーションの実行時に接続の最終的な制御を取得します。

score 1 · Accepted Answer

ここにそれを見る一つの方法があります。どのデータベースを使用するかを決定するのは、どのコンポーネントですか? データベース (または少なくとも接続文字列) が将来変更される可能性があります。どのデータベースを使用するかは Web サイトによって決定されますか? それとも、DAL が決定しますか?

dev、QA、UAT、および prod データベースがある場合、これらの接続文字列を管理することは非常に重要です。

Web サイトが決定した場合、web.config から DAL に接続文字列を渡す必要があります。Web サイトがデータの取得元を認識または気にする必要がない場合、接続文字列は DAL に属します。

score 0 · Accepted Answer

私はこれが古いことを知っていますが、これが私のやり方です（@ Sebaのやり方がとても好きですが、試したことはありません）

これは、DBML ファイルが独自のクラスライブラリに存在することを前提としています。これは、エンティティとデータアクセスを複数の Web サイトや他のクラスライブラリで共有する場合に最も便利であることがわかりました。また、各プロジェクトで接続文字列に同じ名前を付けていることも前提としています。さまざまな環境に展開するときに、NAnt を使用してこれを設定します。

私はこれを@tvanfossonからの上記のトップアンサーに基づいています-その人への称賛。

LinqDataContext から派生する独自の基本クラスを作成する

VBコードは次のとおりです。

    Imports System.Configuration

Public Class CustomDataContextBase
    Inherits System.Data.Linq.DataContext
    Implements IDisposable

    Private Shared overrideConnectionString As String

    Public Shared ReadOnly Property CustomConnectionString As String
        Get
            If String.IsNullOrEmpty(overrideConnectionString) Then
                overrideConnectionString = ConfigurationManager.ConnectionStrings("MyAppConnectionString").ConnectionString
            End If

            Return overrideConnectionString
        End Get
    End Property

    Public Sub New()
        MyBase.New(CustomConnectionString)
    End Sub

    Public Sub New(ByVal connectionString As String)
        MyBase.New(CustomConnectionString)
    End Sub

    Public Sub New(ByVal connectionString As String, ByVal mappingSource As System.Data.Linq.Mapping.MappingSource)
        MyBase.New(CustomConnectionString, mappingSource)
    End Sub

    Public Sub New(ByVal connection As IDbConnection, ByVal mappingSource As System.Data.Linq.Mapping.MappingSource)
        MyBase.New(CustomConnectionString, mappingSource)
    End Sub

End Class

DBML ファイルを開き、[プロパティ] で、上記のクラス名を [基本クラス] プロパティに追加します。

カスタムデータコンテキストクラスを同じアセンブリに配置した場合は、単にクラス名 (例: CustomDataContext) を含めることに注意してください。

それらが異なるアセンブリにある場合は、MyCo.MyApp.Data.CustomDataContext などの完全修飾名を使用します。

Designer が適切に機能するようにするには、接続文字列をクラスライブラリの app.config ファイルにコピーします。これは、IDE 以外では使用されません。

それでおしまい。

接続文字列に同じ名前を付ける必要があります

基本的に行っていることは、DBML ファイルに設定された接続情報を無視するようにデータコンテキストを強制することです。ConfigurationManager メソッドを使用すると、呼び出し元のアセンブリから接続文字列が取得されます。

HTH

score 0 · Accepted Answer

パラメーターとして列挙型を取り、完全に形成された接続オブジェクトを返す ConnectionFactory オブジェクトを定義するのはどうですか?

score 0 · Accepted Answer

データアクセスプロジェクトを使用する必要がある場合は、Web アプリケーションで接続文字列を提供することもできます。コンストラクターの一部にすることができます。

また、データアクセスプロジェクトが呼び出しを行うときに、外部ファイルから接続文字列を読み込む独自のロジックを作成することもできます。

score 0 · Accepted Answer

完璧な世界では、データ層をリファクタリングして、System.Configuration または関連するコンストラクター/ファクトリを介して構成設定を取得すると思います。つまり、暗黙的な構成ソースを再配線するか、ホスト/コンシューマーから明示的に接続を設定する必要があります。これらのタイプの定数を一元化するための別の関連パターンは、読み取り専用プロパティを静的ヘルパークラスにスローし、そのクラスで構成などからの実際の解決を管理することです。

これをエレガントに行う方法の良い例を示していると思われる場所の 1 つは、NHibernate とその構成/マッピング管理です。確かに、これはちょっとした xml 地獄であり、Fluent NHib はもっと甘いですが、実際のサンプルのほとんどは、サポートするアセンブリと実行するアセンブリから構成を調整する方法を示しています。

score 0 · Accepted Answer

.config ファイルに基づいて独自の ConnectionFactory をロールします。

キー/接続文字列のペアをマップするカスタム構成セクションを定義する
必要に応じてホスト名またはマシン名を使用して、その構成セクションにスニッフィングするように ConnectionFactory に教えます
さまざまな dev/qa/prod サーバーのキー/接続文字列の値を入力し、それらをさまざまな app.config、web.config などのファイルにドロップします。

プロ：

すべてがプロジェクト内にあるため、驚くことはありません
展開ターゲットの追加は、.config ファイルでのコピー/貼り付け操作です

短所：

特に多数の運用サーバーがある場合は、大きく醜い XML セクションが作成されます。
プロジェクト間で複製する必要がある
新しいターゲットを追加するにはコードの変更と再デプロイが必要
コードは、それが存在する環境について知る必要があります

.net - .NET / LINQ-SQL / ASP.NET の接続文字列地獄

13 に答える 13

Related

Reference