.NET/LINQ-SQL/ASP.NET中的连接字符串hell

我有一个包含以下内容的web应用程序：

• web项目（具有包含连接字符串的web.config文件，但web项目中没有数据访问代码）
• 使用LINQ-SQL类向web项目UI提供实体的数据访问项目（此项目有一个设置文件和一个app.config，两者都有连接字符串）

在构建和部署时，Bin目录中没有设置文件或app.config以及data access.dll，但是更改web.config文件中的连接字符串不会相应地更改数据库-因此必须将连接字符串编译到data access dll中

我需要的是一个配置文件，用于我的整个部署—网站、数据访问DLL，以及所有—它有一个使用的连接字符串。目前，各地似乎都在使用或硬编码多个连接字符串

我怎样才能最好地解决这个问题

---

感谢您的帮助。

如何定义一个ConnectionFactory对象，它将枚举作为参数并返回一个完整格式的连接对象？

启动项目的配置文件将定义所有包含项目的配置设置。例如，如果您的web项目是启动项目，则对“appSettings”的任何引用都将从web.config中查找设置，这包括对数据访问项目中“appSettings”的任何引用。因此，将任何配置设置从数据访问项目的app.config复制到web项目的web.config。

这里有一种方法可以查看它。哪个组件应该决定使用哪个数据库？将来数据库（或至少连接字符串）可能会更改。网站是否决定使用哪个数据库？还是由DAL决定

如果您有dev、QA、UAT和prod数据库，那么管理这些连接字符串是至关重要的

如果网站决定，它应该将连接字符串从其web.config传递给DAL。

---

如果网站不应该知道或关心数据来自何处，那么连接字符串属于DAL。

您也可以让web应用程序在需要使用数据访问项目时提供连接字符串。你可以让它成为构造函数的一部分

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))
{
   ...
}

---

此外，您可以编写自己的逻辑，以便在数据访问项目进行调用时从外部文件加载连接字符串。

您的应用程序将只使用web.config文件中的配置项。 只要结构正确，就可以将dll配置设置放在web.config文件中。我的示例是使用My名称空间的特定于VB的，但它给出了总体思路

在配置文件的configSections paret中，您需要一个条目：

<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>  

假的

在一个完美的世界中，我认为您应该重构数据层，通过System.configuration或相关构造函数/工厂获取配置设置。也就是说，您要么需要重新连接其隐式配置源，要么显式设置其主机/使用者的连接。集中这些常量类型的另一个相关模式是将只读属性抛出到静态助手类中，并让该类管理来自配置的实际解析，等等

---

我认为可以看到的一个地方是NHibernate及其配置/映射管理，它展示了如何优雅地实现这一点的好例子。诚然，这有点像xml地狱，Fluent NHib更甜，但大多数真实世界的示例将向您展示如何协调支持程序集与执行程序集的配置。

我从未遇到过数据访问层（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))
{
   ...
}

---

基于.config文件滚动您自己的ConnectionFactory：

• 定义自定义配置节以映射键/连接字符串对
• 教您的ConnectionFactory酌情使用主机名或machinename嗅探该配置部分
• 为各种dev/qa/prod服务器填充key/connectionstring值，并将它们放入各种app.config、web.config等文件中

赞成者：

• 所有人都生活在项目中，因此没有什么意外
• 添加其他部署目标是.config文件中的复制/粘贴操作

反对：

• 使XML部分变得非常丑陋，特别是当您有十几台生产服务器时
• 需要在项目之间复制
• 需要更改代码并重新部署以添加新目标
• 代码需要知道它所处的环境

---

根据注册表滚动您自己的连接工厂：

• 在软件/[您的公司]/[您的应用程序]下为您的应用程序添加注册表项
• 为ConnectionString添加字符串值
• 教您的ConnectionFactory打开相应的注册表项（在静态构造函数中，而不是在每次加载页面时！）
• 将注册表信息导出为.reg文件，将其添加到源代码管理中，根据需要修改并应用它以设置其他计算机

赞成者：

• 设置简单
• Connectionstring位于一个单独的位置
• 不是

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

      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