.net 配置问题：在app.config最佳实践中共享模块的连接字符串

我在[app | web].config和依赖于此连接字符串的程序集（例如DAL和Reporting）中声明了连接字符串。配置此类程序集的最佳方式是：

• 在[app | web].config connectionStrings节中使用硬编码连接字符串名称，让程序集通过硬编码名称检索其配置。所以可能会有两个相同的连接字符串：“reportingServer”和“dataSource”

• 使用ConnectionString部分中的唯一连接字符串和您喜欢的任何名称，并通过自定义配置部分将DAL报告程序集配置为使用此名称。现在程序集检索要使用的连接字符串名称，然后检索连接字符串数据

• 通过AppSettings硬编码键配置连接字符串名称。例如，在本例中，您应该始终具有“reportingServerConnectionStringName”和“dataSourceConnectionStringName”键

• 更好的东西我错过了

---

提前谢谢你

您可以查看此问题以了解良好做法：

另外，ASP.NET中的企业连接字符串管理-最佳实践

希望有帮助

//编辑：添加了以下内容

拥有配置文件的主要优势正是您要处理的场景（多个项目和集中配置）

无论采用哪种方式，您都需要为程序集硬编码一些信息，以便能够从App/Web config提取所需信息

出于实际目的，我通常保留两个连接字符串（“reportingServer”和“datasourceServer”），如果需要使它们成为动态的，可以使用两个AppSettings键动态加载所需的连接字符串

一种支持动态加载连接字符串的简单而有效的方法

<appSettings>
<add key="reportingServer" value="reportingServerDev"/>
<add key="dataSourceServer" value="dataSourceServerDev"/>
</appSettings>
<connectionStrings>
<add name="reportingStaging" connectionString="proper connection string"/>
<add name="reportingDev" connectionString="proper connection string"/>    
<add name="dataSourceStaging" connectionString="proper connection string"/>
<add name="dataSourceDev" connectionString="proper connection string"/>
</connectionStrings>

希望这次我的回答是正确的

---

快乐

处理连接字符串通常有两种方法。第一种方式是您在第一个要点中列出的方式

优点是：

• 这很容易
• 如果程序集使用相同的 连接字符串名称，您可以获取 再利用

缺点是：

• 名字是固定的
• 如果您不想为相同的名称使用相同的连接，那么您就被卡住了-尽管在这种情况下重写/使用add&remove元素可能会有所帮助，但我还没有对其进行测试

我使用的另一种技术与ASP.NET成员资格等使用的提供程序模型相同

<configuration>
  <connectionStrings>
    <add name="SqlServices" connectionString="Data Source=localhost;Integrated Security=SSPI;Initial Catalog=aspnetdb;" />
  </connectionStrings>
  <system.web>
    <membership defaultProvider="SqlProvider">
      <providers>
        <add 
          name="SqlProvider" 
          type="System.Web.Security.SqlMembershipProvider" 
          connectionStringName="SqlServices"
          moreSettings="... other settings ..."  />
      </providers>
    </membership>
  </system.web>
</configuration>

优点是：

• 可以跨多个组件重用连接字符串
• 连接字符串名称在程序集中不是硬编码的
• 这种方法更加灵活

缺点是：

• 还有很多工作要做——有时对于一个小项目来说，有些工作做得过火了
• 需要了解如何设置配置节和提供程序（不一定是坏事，有时它们非常有用）
• 配置文件可能会变得更加冗长

---

谢谢，但假设我的问题有点不同。这不是关于如何存储（在安全方面），而是关于如何共享/重用。。有趣。我会等一会儿收集一些统计数据谁和什么更喜欢：）啊，谢谢。您的解决方案是带有自定义配置部分的#2:）它可能真的太过了。