2011-02-18 62 views
0

我希望标题不会太混乱。 这是我打算做的:使用DBML模型,但不同机器上的同一模型使用不同的连接字符串

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

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

所以基本上我有我的网络服务器上的数据库作为一个shell如果你喜欢我可以创建基于Web服务器数据库的关系查询并通过更改连接字符串发送更新的信息返回到我喜欢的任何服务器datacontext。

如前所述,数据库结构在单个数据库和web服务器数据库中将始终保持一致。我将使用我在代码中本地创建的DBML结构来更新数据并更改连接字符串。

让感觉?只是想确认我是否缺少任何东西

回答

0

我们有这样的情况。简化,我们web.config文件中包含类似的条目:然后在代码

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

,您可以:

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

代码使用基于它的运行在机器上的一个不同的连接字符串。

+0

这种方法会将“生产配置细节”泄漏给开发人员 - 并不总是允许的,从来就不是一个好主意。 – belugabob 2011-02-18 12:29:37

+0

@belugabob:堆栈溢出的开发人员拥有生产服务器的管理权限。我认为结果很棒。如果他们有一个每月发布周期,开发人员必须猜测生产环境如何真正起作用,他们不可能走到这么远。 :) – Andomar 2011-02-18 13:13:35

1

只需将所需的连接字符串(或连接)作为构造函数参数传入数据上下文,就可以在运行时执行此操作。您也可以在配置中对其进行配置 - 通常在connectionStrings部分中,但它在一定程度上取决于配置DBML的方式。

0

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

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

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

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

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

相关问题