首先,一些背景知识。我们最近接受了一个大型的MVC3项目。该项目已经准备好在不久前上线,然后客户决定他们想要重新设置整个网站的主题并添加更多功能。他们雇用我们重新设计网站主题,完成剩余的功能并进行部署。
通常它是使用非常清晰,有序的方法构建的,每个数据库表都有一个存储库和一个清晰的服务层,但是有些奇怪的东西让我有点不舒服。继续唠叨我的主要奇怪之处在于,应用程序中的每个存储库和服务都是完全的,100%是静态的(是的,包括写入数据库的方法)。当然,这不允许进行单元测试,但更关心的是当应用程序承受重负载时可能导致的潜在瓶颈和线程问题。我已经看到在舞台服务器上处理请求时出现了一些无法解释的延迟,这就是测试流量的涓涓细流。
应用程序非常庞大,重建它以使用IOC /每个请求实例化的存储库几乎是不可能的。
我可以做些什么来避免部署时潜在的线程问题?每次写入都需要时,我可以使用连接池并借用数据库连接吗?
提前致谢:)
编辑 - 这是创建实体模型实例的一些代码。每个静态方法都调用此“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;
}
}
`
专利
答案 0 :(得分:6)
我在这里假设您的存储库类只包含静态方法,而不是任何静态方法。
无状态静态类的好处是它们可以安全地转换为具有默认无参数构造函数的常规类,并且不会担心它们的生命周期。然后,为测试目的提取接口将是一个简单的案例。
每当您需要与存储库通信时,只需实例化一个。
除非应用程序在使用存储库期间使用共享状态执行某些操作,否则您不必担心多线程访问。数据库本身负责处理许多并发调用。
目前所有的瓶颈和线程问题都是潜在的,有时我们对可能出错的有根据的猜测是自己错误 - 尤其是多线程。减速可能只是因为数据库没有处理过多请求的咕噜声。