使用 DBML 模型，但不同机器上相同模型的连接字符串不同答案

【问题标题】：Use DBML model but different connection string for same model on different machine使用 DBML 模型，但不同机器上相同模型的连接字符串不同
【发布时间】：2011-02-18 20:28:43
【问题描述】：

我希望标题不要太混乱。这是我打算做的：

假设我在全国 10 个单独的站点中有 10 台单独的服务器。他们有一个数据库和前端桌面应用程序。

现在我有一个网站，我拥有与 10 台服务器相同的数据库结构/模型。我使用 LINQ to SQL 设置查询，在执行查询之前我将更改 DataContext 的连接字符串。

所以基本上我的网络服务器上有数据库，如果你愿意的话，我可以用作外壳，我可以根据网络服务器数据库创建关系查询，并通过更改连接字符串将更新的信息发送回我喜欢的任何服务器数据上下文。

如前所述，数据库结构在单个数据库和网络服务器数据库中始终相同。我将使用我在代码中本地创建的 DBML 结构来更新数据并更改连接字符串。

有意义吗？只是想确认我是否遗漏了什么

【问题讨论】：

标签： c# asp.net sql linq

【解决方案1】：

您可以在运行时执行此操作，只需将所需的连接字符串（或连接）作为构造函数参数传递到数据上下文中即可。您也可以在配置中进行配置 - 通常在 connectionStrings 部分中进行配置，但这在一定程度上取决于 DBML 的配置方式。

【讨论】：

【解决方案2】：

我们的情况很像这样。简化后，我们的web.config 文件包含以下条目：

<appSettings>
    <add key="server1_ConnectionString" value="Data Source=myServerAddress;..."/>

然后在代码中，你可以：

use (var dc = new DbDataContext(ConfigurationManager.AppSettings[
                  System.Environment.MachineName.ToLower + "_ConnectingString"]))
{
    ....

代码根据运行它的机器使用不同的连接字符串。

【讨论】：

这种方法会向开发人员“泄露”生产配置详细信息 - 并非总是允许，也不是一个好主意。
@belugabob：Stack Overflow 的开发人员拥有生产服务器的管理员权限。我认为结果很棒。如果他们有一个每月发布周期，开发人员必须猜测生产环境的真正工作方式，他们就不可能走到这一步。 :)
中肯的评论，我想这确实取决于您的工作实践以及它们的严格程度。
感谢大家的及时回复。如果我更详细地解释一下，你介意再看看我的方法吗...所以是的，我在网络配置中设置了一堆连接字符串。然后我在 sql 的表中拥有用户名和用户位置。当用户登录网站时，我会识别用户的位置并将连接字符串添加到数据上下文（其中位置与 web.config 中连接字符串的位置名称匹配）然后我执行查询针对该位置的相关数据库。可以这样做，是吗？

【解决方案3】：

我使用的解决方案是从 web.config 中完全删除连接字符串，并在包含您的网站的 IIS 上下文中定义它。通过使用类似命名空间的命名约定，如“YourAppName.ConnectionString”，您可以避免多个应用程序之间的冲突。

这种方法的优点是多方面的...

相同的部署文件可用于每个环境，每个环境都有自己的配置
部署新版本不应干扰任何现有配置或要求系统管理员每次都编辑 web.config
由于连接字符串可能包含用户名和密码，因此开发人员无法获得用于生产环境的这些值。
对连接字符串的更改不需要应用程序保持同步。

为了采用这种方法，您需要警惕 Visual Studio 将连接字符串添加回 web.config 文件，并且在更改您的 DBML 之后，此使用的默认连接字符串可能会更改。在这两种情况下，只需使用您的版本控制系统来管理这些更改的回滚。

它可能不适合你，但我很高兴这样做。

【讨论】：

唯一的是，我需要使用一系列连接字符串，具体取决于用户登录时所属的位置。这就是我将它们保留在配置中的原因。这有意义吗？
我刚刚再次阅读了您的问题-我不得不说我不记得以前阅读过它-您是否对其进行了编辑以使其更清晰？无论如何，鉴于上述解释，Marc Gravell 给出的答案听起来是正确的。我唯一不确定的是多个用户的稳定性如何，每个用户都使用自己的数据上下文。