4

First, some background. We have recently taken on a large MVC3 project. The project was pretty much ready to go live some time ago, then the client decided they wanted to re-theme the whole website and add a load more functionality. They employed us to re-theme the site, finish off the remaining functionality and deploy it.

Generally it is built using a very clear, ordered approach, with one repository for each database table and a clear service layer, however there are some oddities that are making me slightly uncomfortable. The main oddity that keeps on nagging at me is that every single repository and service in the application is completely, 100% static (yes, including methods that write to the db). Of course, this doesn't allow for unit testing, however a greater concern is the potential bottlenecks and threading issues that will cause when the application comes under a heavy load. I am already seeing some unexplained delays in processing requests on the stage server, and that is with a trickle of testing traffic.

The application is so huge that rebuilding it to use IOC/instantiated-per-request repositories is pretty much out of the question.

What can I do to avoid potential threading issues upon deployment? Could i use a connection pool and borrow a db connection each time a write needs to happen?

Thanks in advance :)

Edit - here is some of the code that creates an instance of the entity model. Each static method calls this 'DemoEntities' method to obtain an instance of the entity model, which it then uses to execute the db commands. I can see here that, though the method is static, it is actually checking the HttpRequest for a pre-existing instance and creating one if it doesn't already exist. As such, I think we'll be ok.

   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;
       }
   }

`

Pat

4

1 回答 1

6

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

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

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

除非应用程序在存储库使用期间使用共享状态做某事，否则您不需要担心多线程访问。数据库本身负责处理许多并发调用。

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

于 2012-06-06T15:05:18.163 回答