Is Repository Singleton or Static or None of these?

Static and singleton aren't good solution for Repository pattern. What if your application will use 2 or more repositories in the future?

IMO the best solution is to use a Dependency Injection container and inject your IRepository interface in the classes that need it.

I suggest you to read a good book about domain driven design and a good book about dependency injection (like Mark Seeman's Dependency Injection in .NET).

With singletons and static classes your application won't be scalable

You have two singleton repositories:

class Repository<TEntity> {  static Repository<TEntity> Instance { get { ... /*using sql server*/ } }}class Repository2<TEntity> {  static Repository2<TEntity> Instance { get { ... /*using WCF or XML or any else */ } }}

The services using them must have a static reference to one of them or both:

class OrderService {    public void Save(Order order) { Repository<Order>.Instance.Insert(order); }}

How can you save your order using Repository2, if the repository is statically referenced?

A better solution is using DI:

interface IRepository<TEntity> { ... }class SqlRepository<TEntity> : IRepository<TEntity> { ....}class OrderService {    private readonly IRepository<TEntity> _repo;    public OrderService(IRepository<TEntity> repo) { _repo = repo; }    public void Save(Order order) { repo.Insert(order); }}

Don't use static or singleton repositories because of:

• It affects testablility, you can not mock it when unit testing.

• It affects extensibility, you can not make more than one concrete implementation and you can not replace behavior without re-compiling.

• It affects scalability in terms of lifecycle management, insetead depend on dependency injection framework to inject the dependency and manage lifecycle.

• It affects maintainability, it forces dependency upon concrete implementation instead of abstraction.

Bottom line: DONT use static or singleton repositories

instead create repository interfaces in your domain model project, and implement these interfaces in a concrete data access project, and use dependency injection framework.

Two SOLID reasons to not have singleton repository:

• Consumers of repository will be coupled to repository implementation. This will negatively affect extensibility and testabiliy. This is a DIP violation. Depend on abstractions, not on concretions.

• Repository implementation will have to violate SRP because it will most likely end up managing ORM session, database connection and potentially transactions. It would also have to make thread safe guarantees because it potentially can be used from multiple threads. Instead, database connection (ORM Session) should be injected into repository implementation so that consuming code can arrange multiple repository calls into transaction.

Possible solution to both problems is Constructor Injection.