Can repository class be scoped as singleton in ASP.NET

Question

I am trying to understand the scope of repository class in ASP.NET application. I assume they are thread safe in request scope since each request runs on a seperate thread. But how about having it singleton, is it a valid scenario.

Because these classes doesn't have state but only methods which manipulate data, so different threads executing these methods might be having different stack frames. Is my understanding right, could anyone provide more insights.

interface ICustomerRepository
{
   List<Customers> GetAll();
   Customer GetById(int id);
}

public class Customer : ICustomerRepository
{
   //implement methods

}

As mentioned I would like to know about how singleton works. — Sunny, Mar 29 '13 at 16:05
Look here: [Example of Singleton pattern](http://stackoverflow.com/questions/2585022/example-of-singleton-pattern/2585104#2585104). Or this article by the infamous @JonSkeet: [Implementing the Singleton Pattern in C#](http://csharpindepth.com/Articles/General/Singleton.aspx) — Shai Cohen, Mar 29 '13 at 16:10
I've idea about singleton since this is an web application, it made me ask this question esp. in this scenario. IOC container has different scopes like request, singleton, transient, etc, so would like to know how it applies in ASP.NET. — Sunny, Mar 29 '13 at 16:14
Also, I am not sure what, if any, benefits you would get from going the singleton route. IMHO, repository classes, and their methods, should be marked as static. This will meets your desire of of not having object references in the heap. — Shai Cohen, Mar 29 '13 at 16:16
In an ASP.NET app, the singleton class will exists in the application scope, not on a per-session basis. ALL requests to the singleton class will use the object in the application scope. Does this answer your question? — Shai Cohen, Mar 29 '13 at 16:18
No, as mentioned, whether these repository objects and their methods are thread safe with singleton. And how the memory consumption will be. I know it works with Request scope or by having static helper methods since each request runs in its own thread. Here, I am asking concept wise w.r.t this scenario. — Sunny, Mar 29 '13 at 16:23
If you're using the EF or many other ORMs, be aware that they are not thread-safe so the singleton pattern is definitely _not_ the way to do. Also, think about what's going to happen when you get into the realms of the UnitOfWork pattern - how exactly should transactions work when updates could be coming from multiple threads? — Basic, Apr 03 '13 at 15:05
I'm unfamiliar with micro ORM. ADO.Net is not inherently an ORM so whether or not it would be thread-safe depends entirely on how you implemented an ORM on top of it, the proxy classes/state tracking/lazy loading/etc that you write. I think you'll find there's no reason to have this as a singleton and a _lot_ of problems to overcome if you do. Why are you opposed to creating one per thread/transaction/context? There's no reason not to have the _factory_ for the repositories as a singleton — Basic, Apr 03 '13 at 15:10

score 6 · Accepted Answer · answered Apr 03 '13 at 18:18

Exposing a repository as a singleton for a concurrent environment is a bad idea.

You could possibly implement interface repository in a way that is safe to be used concurrently but this means that the only guarantee of concurrency consistency lies somewhere in the implementation. There is no other mechanism to enforce that concurrent calls would not fail, the contract at the programming language level (repository interface) is just too weak to express such requirement.

On the other hand, if each http context gets its own instance, the implementation details do not matter.

I suggest you read more on object lifetime. A singleton is just a specific example of a more general idea of controlling the lifetime. You can have objects with transient lifetime, objects that are shared in a single instance for the lifetime of you application but also objects that live in a context of a thread or an http context (that possibly spans multiple threads). And one of ways to control the lifetime is to have a factory that creates instances.

If you need something simple, you could have something that looks like a singleton but controls the lifetime in an arbitrary way:

http://netpl.blogspot.com/2010/12/container-based-pseudosingletons-in.html

Can repository class be scoped as singleton in ASP.NET

1 Answers1