【问题标题】:Entity Framework in Asp.Net MVCAsp.Net MVC 中的实体框架
【发布时间】:2012-07-22 00:51:03
【问题描述】:

我的 ASP.Net MVC 应用程序必须在运行时连接到多个数据库。我可以重载我的类以在运行时接受连接字符串,如下所示

class MyClassDBContext:DbContext
{
  public MyClassDBContext(string str) : base(str)
  {
    this.Database.Connection.ConnectionString = str;
  }
}

目前,我正在从数据库表中检索此连接字符串。我的工作流程如下

  1. 网站使用存储在 web.config
  2. 网站查询默认数据库以获取连接字符串 其他数据库。
  3. 网站通过提供连接连接到其他数据库 运行时的字符串

我现在面临的问题是保持我的代码干净。每次我需要数据库 2 的连接字符串时,我都必须在默认数据库中查找它。有没有更清洁的方法来做到这一点?我考虑将连接字符串存储在配置文件数据中,但我不确定这是否是个好主意。我网站的每个用户最多需要连接到 2-3 个不同的数据库,具体取决于他们的凭据。

【问题讨论】:

  • 为什么不在 web.config 中定义所有连接字符串?
  • @m0s - 不同的客户端连接到不同的数据库。我正在提前考虑,觉得随着客户数量的增加,web.config 会变得混乱。
  • 确保您正在加密存储在默认数据库中的连接字符串...顺便说一句,我正在用我的桌面应用程序做同样的事情,并且经历了想知道是否有更好的方法,但想不出一个,所以我很想看看是否有人可以发布更好的解决方案......
  • @Dean K - 是的,我已经加密了我的连接字符串。感谢您将其添加为评论,因为这是许多开发人员跳过的非常有价值的一步

标签: c# asp.net-mvc-3 entity-framework


【解决方案1】:

我遇到了一个稍微不同的问题。我连接的数据库取决于产品导入的状态。在导入期间,数据库会被附加和分离。当前可用的数据库存储在“默认数据库”中。

我遇到的主要问题是我必须关闭连接池,否则在分离数据库并再次附加它们后会出现无效的连接状态。

这对你来说可能不是问题。

除此之外,我将当前的 Connectionstring 存储在应用程序状态中。仅在每 60 秒后,我才再次查询“默认数据库”。您必须通过使用锁定来注意多线程问题。

【讨论】:

    【解决方案2】:

    我会亲自将所有连接字符串放入您的 App.Config 文件并使用简单的 IOC 实现。

    实际上,Nuget 的 ninject 包可能非常适合您的需求。

    这就是我的意思。希望这使您的代码干净。我在之前的项目中使用了完全相同的模式,并且效果很好。

    您可以更进一步,在您的 global.asax 中制作服务定位器并注册服务。如果您对此感兴趣,请告诉我。另请查看 ninject。

    public interface IService() 
    { 
      string GetConnectionString(); 
      void DoStuff(); 
    }
    
    public class DBServiceOne : DbContext, IService
    {
      protected string GetConnectionString() 
      {
        return ConfigurationManager.AppSettings["DBServiceOneConnectionString"]
      }
    
      public DBServiceOne(string str) : base(str)
      {
         this.Database.Connection.ConnectionString = GetConnectionString()
      }
    
       public void DoStuff() { //logic goes here }
    }
    
    public class DBServiceTwo : DbContext, IService
    {
    
        public DBServiceTwo(string str) : base(str)
        {
          this.Database.Connection.ConnectionString = GetConnectionString();
        }
    
    
        protected string GetConnectionString() 
        {
          return ConfigurationManager.AppSettings["DBServiceTwoConnectionString"]
        }
    
        public void DoStuff() { //logic goes here }
    }
    
    public class DBServiceThree : DbContext, IService
    {
    
       public DBServiceThree(string str) : base(str)
       {
         this.Database.Connection.ConnectionString = GetConnectionString();
       }
    
       protected string GetConnectionString() 
       {
         return ConfigurationManager.AppSettings["DBServiceThreeConnectionString"]
       }
    
       public void DoStuff() { //logic goes here }
    }
    

    现在开始实施——在控制器上使用构造函数注入

    //This could be in your home controller
    
    public class HomeController : AsyncController
    {
        private IService DBOneService;
        private IService DBTwoService;
        private IService DBThreeService;
    
       public HomeController(IService one, IService two, IService three)
       {
          DBOneService= one;
          DBTwoService = two;
          DBThreeService = three;
       }
    
      public HomeController() : this(new DBServiceOne(), new DBServiceTwo(), new DBServiceThree()) {}
    
    public ActionResult Index() {
       DBOneService.DoStuff(); //here you'd want to return a list of data and serialize down with json or populate your razor template with it. Hope this helps!
    
    }
    

    【讨论】:

    • 感谢详细的代码。我不确定这是否会减少我的工作流程,因为我仍然必须每次都查找默认数据库以检查用户必须连接到哪个辅助数据库。也许我可以使用您的代码和我的代码创建一个混合体。我可以将数据库名称存储在用户配置文件中,然后从配置文件中查找连接字符串。我会等着看是否有人有更好的主意。如果没有,我会接受你的解决方案作为答案。
    • 为什么数据库中的db连接字符串放在首位?你能把所有的数据库加入一个数据库吗?
    • 那么当您需要更改连接字符串时会发生什么? app.config 的简单更新是不够的...
    • @David Johnson - 不幸的是,这个决定不是我的决定。我正在开发的应用程序的业务规则需要每个客户都有自己的数据库。根据客户对托管的偏好,这些数据库也可以位于不同的位置。这就是为什么我被存储在表中的连接字符串所困扰。我还应该提到,所有这些数据库中都有相同的表。唯一的区别在于存储的数据
    • 对于这种模式来说,让所有数据库都有完全相同的表并不一定是坏事。查询可以完全相同。如果你不喜欢这个实现,或者想把它带到一个抽象层次,那么就创建一个抽象基类并让它实现接口。让所有 DBService 类继承它,然后覆盖它们。实际上,你也可以用虚方法使它成为一个抽象类。所以这样你就可以提供一个默认的实现,这就是我要走的路。如果你想让我给你看,请告诉我。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-05-26
    • 2010-09-25
    • 1970-01-01
    • 2012-10-18
    • 2011-02-20
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多