【问题标题】:Static Repositories - Workaround静态存储库 - 解决方法
【发布时间】:2012-06-10 14:59:59
【问题描述】:

首先,一些背景。我们最近接手了一个大型 MVC3 项目。不久前,该项目几乎已经准备好上线,然后客户决定他们想重新设置整个网站的主题并添加更多功能。他们聘请我们重新设计网站的主题,完成剩余的功能并进行部署。

通常它是使用一种非常清晰、有序的方法构建的,每个数据库表都有一个存储库和一个清晰的服务层,但是有些奇怪的地方让我有点不舒服。一直困扰我的主要怪事是应用程序中的每个存储库和服务都是完全 100% 静态的(是的,包括写入数据库的方法)。当然,这不允许进行单元测试,但更令人担忧的是当应用程序承受重负载时会导致的潜在瓶颈和线程问题。我已经看到在舞台服务器上处理请求时出现了一些无法解释的延迟,这与测试流量有关。

该应用程序非常庞大,因此几乎不可能重建它以使用 IOC/instantiated-per-request 存储库。

如何避免在部署时出现潜在的线程问题?每次需要写入时,我可以使用连接池并借用数据库连接吗?

提前致谢:)

编辑 - 这是一些创建实体模型实例的代码。每个静态方法都调用这个“DemoEntities”方法来获取实体模型的一个实例,然后用它来执行 db 命令。我可以在这里看到,虽然该方法是静态的,但它实际上是在检查 HttpRequest 中是否存在预先存在的实例,如果它不存在则创建一个。因此,我想我们会没事的。

   public static DemoEntities DemoEntities
   {
       get
       { 
           if (HttpContext.Current != null && HttpContext.Current.Items["DemoEntities"] == null) 
           {
               HttpContext.Current.Items["DemoEntities"] = new DemoEntities(); 
           }
           return HttpContext.Current.Items["DemoEntities"] as DemoEntities;
       }
       set
       {
           if (HttpContext.Current != null)
               HttpContext.Current.Items["DemoEntities"] = value;
       }
   }

`

拍拍

【问题讨论】:

  • 您能否展示一些示例线程问题和解决方案瓶颈的代码?此外,我不喜欢以这种方式使用静态类,这不是问题。也许您可以显示存储库的状态(静态)的形式(可能是数据库连接?Datacontext?)
  • 此代码块似乎显示了实现单例模式以创建每个线程实例而不是真正的静态对象的尝试。我不确定这是否是单身人士的最佳方法,因为没有做任何事情来锁定任何东西;如果由于同步问题在同一个线程上创建了两个演示实体实例,那会是“坏的”吗?另外,为什么每个线程一个?

标签: c# asp.net-mvc asp.net-mvc-3 model-view-controller inversion-of-control


【解决方案1】:

我在这里假设您的存储库类仅包含静态方法,而不包含任何静态状态。

无状态静态类的好处是它们可以安全地转换为具有默认无参数构造函数的常规类,并且无需担心它们的生命周期。然后,提取一个用于测试目的的接口将是一个简单的案例。

当您需要与存储库通信时,只需实例化一个。

除非应用程序在使用存储库期间使用共享状态执行某些操作,否则您无需担心多线程访问。数据库本身负责处理许多并发调用。

目前所有瓶颈和线程问题都是潜在的,有时我们对可能出错的有根据的猜测本身是错误的——尤其是多线程。速度变慢可能仅仅是因为数据库没有足够的能力来处理太多的请求。

【讨论】:

  • 感谢您的回答,听起来我们在这种情况下可能没问题。请参阅我即将在 Filburt 的评论中发布的代码。
猜你喜欢
  • 1970-01-01
  • 2014-03-19
  • 2010-12-16
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-02-22
相关资源
最近更新 更多