【问题标题】:Where to store connection string in a 3-tier winform application using C# 4.0使用 C# 4.0 在 3 层 winform 应用程序中存储连接字符串的位置
【发布时间】:2011-08-22 15:34:38
【问题描述】:

我们即将使用 winforms 实现一个应用程序。我想要一个 3 层架构(GUI、业务逻辑和数据访问层。

我们每个客户都有一个数据库,因此我们必须能够使用该应用程序访问不同的数据库(也可能在不同的服务器上)。例如。客户 A 在服务器 A 上,客户 B 在服务器 B 上。

编辑: 部署场景:这个应用程序可能安装在 ServerA 上,但数据库可能安装在 ServerA、ServerB、ServerC、ServerX 上(我想你明白了)。

从数据库读取数据库连接有点复杂,因为我不知道用户想要连接到哪个数据库。最重要的是,用户 ID 仅在同一个数据库中是唯一的,因此具有用户名(例如“admin”)的用户可以存在于多个数据库中:)

我们希望能够登录应用程序,提供用户名、密码和连接字符串信息。现在,如何将连接字符串信息发送到 DAL,以便 GUI 和业务层不必知道数据库连接字符串?我不想将连接字符串存储在 GUI 项目中,并将其作为参数传递给业务层,而业务层又在每次我需要数据库中的一些数据时将连接字符串传递给 DAL。

编辑:连接字符串信息只需要在用户登录时可用。一旦他注销,此信息应被删除)

我在一个继承自 ApplicationSettingsBase 的新项目中实现了一个类(UI 项目和 DAL 项目都有对新项目的引用)。所以我现在可以保存连接信息(默认保存到 user.config 文件)。因此,我可以从用户界面实例化该类并通过调用 base.Save 来存储连接信息,然后在 DAL 中我可以实例化同一个类并在那里读取连接信息。不确定我是否喜欢该解决方案,因为 user.config 文件与 windows 用户绑定(通过将文件存储在 C:\Users...\AppData\ 层次结构中,我不确定这样做的性能方式。也许是矫枉过正?

编辑:我还没有找到令人满意的解决方案,所以我感谢社区提供的更多答案:)

编辑:

我找到了解决这个问题的方法。我只在一个小型测试项目中测试了解决方案,但这里是:

用户登录,负责检索登录信息的 UI 方法运行此方法:

public void SetTempSetting()
{
       // Get the configuration file.
       Configuration config  = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);           

       // Add the connection string.
       ConnectionStringsSection csSection = config.ConnectionStrings;
                csSection.ConnectionStrings.Add(new ConnectionStringSettings("ConnectionStringName", GetConnectionString()));

      // Save the configuration file.
      config.Save(ConfigurationSaveMode.Modified);

}

SetTempingSetting() 方法会将连接字符串写入 ProjectName.dll.config

在 DAL 项目中,我可以像这样从 ConfiguraionManager 获取连接字符串:

var connectionstring = ConfigurationManager.ConnectionStrings["ConnectionStringName"].ConnectionString;

当用户退出应用程序时,logout 方法可以执行该方法从 Project.dll.config 中删除连接字符串

public void RemoveTempSetting()
        {
            // Get the configuration file.
            Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);            
            // Add the connection string.
            ConnectionStringsSection csSection = config.ConnectionStrings;
            csSection.ConnectionStrings.Remove("ConnectionStringName");
            // Save the configuration file.
            config.Save(ConfigurationSaveMode.Modified);            
        }

对此解决方案有任何想法吗?优点?缺点?过度设计?糟糕的设计?

【问题讨论】:

  • 这些独立的客户数据库是否具有相同的架构?您是否有某些合同或监管原因将它们分开?我们有类似的东西,最终将 DB 合二为一。然后添加新客户只需在“客户”表中添加一行。扩展性更好,新客户端启动更快,始终相同的连接字符串等等。
  • 我们有单独的客户数据库只是历史原因。 (请不要问我为什么:))。模式是相同的。所以这是一个如何使用多个连接字符串的问题。
  • 在一个单独的项目中拥有一个包含连接信息的静态类,然后在 GUI 项目和 DAL 项目中引用该项目是否是一个想法?
  • OKB,如果您解决了您的问题,您应该将其添加为答案,而不是将其添加到问题中。这样可以更好地找到您的答案,并可能为您赢得一些支持。

标签: c# winforms 3-tier


【解决方案1】:

在我看来,连接字符串应该存储在数据访问层中。

【讨论】:

  • 那么我也更喜欢,但是在我的情况下如何实现呢?
【解决方案2】:

您的 DAL 需要某种配置数据库。它需要知道如何连接到配置数据库,询问特定客户的连接信息,然后使用它来解决查询。据推测,您正在将客户 ID 传递给 DAL。

我认为它应该属于 DAL,而不是属于您的业务对象或表示层,作为连接信息,其本质上是特定于实现的。

“配置数据库”是配置文件,还是其他东西是设计/实现选择。例如,没有什么可以阻止您将连接字符串作为用户属性存储在 LDAP 中(每个客户 1 个 LDAP 用户)。

【讨论】:

  • 感谢您的回答,但这对我没有多大帮助,因为应用程序在用户登录之前对它需要连接的数据库一无所知(并提供数据库连接信息)
  • @OKB:尝试阅读各种服务发现标准 (en.wikipedia.org/wiki/Service_discovery)。这可能会告诉你一条路径。
【解决方案3】:

这就是我的做法。我将连接字符串保存在 GUI 中,但不会传递它。

  1. 创建DataLayer,连接数据库,本例我使用Entity Framework。它会自动创建 app.config 和连接字符串

/Model1.csdl|res:///Model1.ssdl|res://*/Model1.msl; provider=System.Data.SqlClient;provider connection string="Data Source=DEV;Initial Catalog=ECOM;Integrated Security=True;MultipleActiveResultSets=True;Application Name=EntityFramework"" providerName="System.Data.EntityClient" />'

  1. 我将上面的连接字符串复制并粘贴到 GUI 的 App.config 文件中

  2. 然后我删除数据层的 app.configure 文件。

【讨论】:

  • 我想你误解了我的问题 vnRock,但还是谢谢
【解决方案4】:

支持多个客户始终是一项挑战。我对这个问题的解决方案是为每个数据库类型创建一个 DAL,它们都使用相同的定义接口。在程序启动时,我根据客户配置实例化了适当的 DAL 实例。我向 DAL 传递了一个令牌,该令牌是对 DAL 配置文件中适当连接字符串的引用(DAL 是 Web 服务中间层的一部分)。我从这里记忆,所以我希望我得到所有细节正确,但是主要概念是使用依赖注入来实例化适当的 DAL,然后设置实例化 DAL 的属性,允许它检索适当的连接字符串,从而消除了在客户端存储连接字符串的需要。因此,在登录时,可以为用户提供一个令牌列表(表示连接字符串),他们对其具有适当的权限(通过用户配置完成),或者每个用户都可以有一个默认令牌,这让他们可以访问数据库具有最少的凭据条目。

【讨论】:

    猜你喜欢
    • 2011-04-19
    • 2015-04-12
    • 2019-08-22
    • 2011-10-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多