c# with Advantage of using Interface over abstract class for repository pattern?




why interface is preferred over abstract class (6)

Possible Duplicate:
Interface vs Base class

Its common to see the repository pattern implemented using Interfaces

public interface IFooRepository
{
   Foo GetFoo(int ID);
}

public class SQLFooRepository : IFooRepository
{
   // Call DB and get a foo
   public Foo GetFoo(int ID) {}
}

public class TestFooRepository : IFooRepository
{
   // Get foo from in-memory store for testing
   public Foo GetFoo(int ID) {}
}

But you could equally do this using abstract classes.

public abstract class FooRepositoryBase
{
    public abstract Foo GetFoo(int ID);
}

public class SQLFooRepository : FooRepositoryBase
{
    // Call DB and get a foo
    public override Foo GetFoo(int ID); {}
}

public class TestFooRepository : FooRepositoryBase
{
    // Get foo from in-memory store for testing
    public override Foo GetFoo(int ID); {}
}

What are the specific advantages of using an Interface over an Abstract Class in a repository scenario?

(i.e. don't just tell me that you can implement multiple interfaces, I know this already - why would you do that in a repository implementation)

Edit to clarify - pages like "MSDN - Choosing Between Classes and Interfaces" can be paraphrased as "Choose classes over interfaces unless there is a good reason not to" - what are the good reasons in the specific case of a Repository pattern


This is a general question that applies to any class hierarchy, not just repositories. From a pure OO point of view, an interface and a pure abstract class are the same.

If your class is part of a public API, the primary advantage of using an abstract class is that you can add methods in the future with little risk of breaking existing implementations.

Some people also like to define an interface as "something that a class can do" and a base class as "what a class is", and therefore will only use interfaces for peripheral capabilities and always define the primary function (eg. repository) as a class. I'm not sure where I stand on this.

To answer your question, I don't think there is any advantage to using an interface when it defines the primary function of the class.


The main advantage of using an interface over an abstract class in this instance is that an interface is entirely transparent: This is more of an issue where you don't have access to the source of the class you're inheriting from.

However, this transparency allows you to produce unit tests of a known scope: If you test a class that accepts an interface as a parameter (using the dependency injection method), you know you're testing the class with a known quantity; the testing implementation of the interface will only contain your testing code.

Similarly, when testing your repository, you know you're testing just your code in the repository. This helps to limit the number of possible variables/interactions in the test.


Take a look at the implementation of Tim McCarthy's Repository Framework. < http://dddpds.codeplex.com/ >

He uses interfaces like IRepository<T> for defining the contracts, but he also uses abstract classes like RepositoryBase<T> or his SqlCeRepositoryBase < T > that implements IRepository<T>. The abstract base class is code to eliminate a lot dublicate code. A type specific repository just have to inherit frome the abstract base class and needs to add the code for its purpose. Users of the API can just code against the interface by contract.

So you can combine both approaches to use the advantages of them.

Additionally, I think most IoC-Frameworks can handle abstract classes.


While others may have more to add, from a purely practical point of view, most IoC frameworks work better with interface -> class mappings. You can have different visibilities on your interfaces & classes, whereas with inheritance, the visibilities must match.

If you're not using an IoC framework, from my point of view there is no difference. Providers are based on abstract base classes.


Since the pattern originates in Domain Driven Design, here's a DDD answer :

The contract of a Repository is usually defined in the Domain layer. This allows objects in the Domain and Application layers to manipulate abstractions of Repositories without caring about their real implementation and the underlying storage details - in other words, to be persistence-ignorant. Besides, we often want specific behaviors to be included in the contracts of some repositories (in addition to your vanilla Add(), GetById(), etc.) so I prefer the ISomeEntityRepository form than just IRepository<SomeEntity> - we'll see why they need to be interfaces later.

The concrete implementations of Repositories, on the other hand, reside in the Infrastructure layer (or in the Tests module for test repositories). They implement the above repository contract but also have their own range of persistence-specific characteristics. For instance, if you're using NHibernate to persist your entities, having a superclass to all the NHibernate repositories with the NHibernate session and other NHibernate-related generic plumbing in it could come in handy.

Since you can't inherit several classes, one of these 2 things that your final concrete Repository inherits has to be an interface.

It's more logical for the Domain layer contract to be an interface (ISomeEntityRepository) since it's a purely declarative abstraction and mustn't make any assumption about what underlying persistence mechanism will be used - i.e. it mustn't implement anything.

The persistence-specific one can be an abstract class (NHibernateRepository or NHibernateRepository<T> in the Infrastructure layer) which allows you to centralize there some behaviors that are common to the whole range of persistent-store-specific repositories that will exist.

This results in something like :

public class SomeEntityRepository : NHibernateRepository<SomeEntity>, ISomeEntityRepository 
{
  //...
}

I guess the key difference would be, that an abstract class can contain private properties & methods, wherein an Interface cannot, as it's only a simple contract.

The result being an interface is always "no shenanigans here - what you see is what you get" whilst an abstract base class may allow side effects.





architecture