Agnostic repository

// Sample code in C#
// This interface would define more methods, but 
// there's just one to simplify the reasoning.
public interface IRepository<T>
{
    void Add(T someObject);
}

// Probably you don't want to repeat yourself in terms of implement basic
// CRUD operations across your solution. Thus, you would end up creating
// a base class which would be associated with some data mapper of your choice.
// Change SomeDataMapper with who knows what OR/M, micro OR/M, NoSQL client
// or whatever ;)
public abstract class Repository<T> : IRepository<T>
{
    public Repository(SomeDataMapper dataMapper)
    {
        DataMapper = dataMapper;
    }

    private SomeDataMapper DataMapper { get; }

    public virtual void Add(T someObject)
    {
        DataMapper.InsertOne(someObject);
    }
}

// Imagine you want some specialization to share how repositories validate
// domain objects across your entire solution. You would end up creating
// a base class like the following one.
// Oops! You would be able to specialize this validatable repository
// unless some domain requires a repository which isn't tied to 
// Repository base class' data mapping technology...
public abstract class ValidatableRepository<T> : Repository<T>
{
    public Repository(IList<ISpecification<T>> specifications, SomeDataMapper dataMapper)
        : base(dataMapper)
    {
        Specifications = specifications;
    }

    private IList<ISpecification<T>> Specifications { get; }

    public override void Add(T SomeObject)
    {
        if(Specifications.All(spec => spec.IsSatisfiedBy(someObject)))
        {
            base.Add(someObject);
        }
    }
}

// You would define an interface to implement methods that go beyond
// basic CRUD from the repository interface.
public interface ICustomerRepository : IRepository<Customer>
{
    IList<Customer> GetTopCustomers(int maxResults = 10);
}

// Finally, you would both inherit validatable repository because you want
// to validate your domain objects using the approach implemented across your
// solution. But... Oops (again!). Your customer repository is still coupled
// with an specific data mapper technology, because it inherits the so-called
// validatable repository!
public class CustomerRepository : ValidatableRepository<Customer>, ICustomerRepository
{    	
    public CustomerRepository(IList<ISpecification<T>> specifications, SomeDataMapper dataMapper)
        : base(specifications, dataMapper)
    {
    }

    public IList<Customer> GetTopCustomers(int maxResults = 10)
    {
        return DataMapper.OrderByDescending(customer => customer.Sales.Count)
                    .Take(maxResults)
                    .ToList();
    }
}

// #1 We define a sample repository interface. A complete one
// would define methods for all basic CRUD operations.
public interface IRepository<T>
{
    void Add(T someObject);
}

// #2 We implement the whole agnostic repository. It's the one that
// will contain anything unrelated to data mapping technology.
// 
// Persistence will be handled by the believer repository, the one that
// will be coupled to a data mapping technology, but the agnostic repository
// will just rely on the injected repository to persist objects.
public abstract class AgnosticRepository<T> : IRepository<T>
{
    // #3 We receive both the believer repository and a collection of
    // specification to validate incoming object to be persisted somehow
    // using the believer repository!
    public AgnosticRepository(IRepository<T> believerRepository, IList<ISpecification<T>> specifications)
    {
        BelieverRepository = believerRepository;
        Specifications = specs;
    }

    private IRepository<T> BelieverRepository { get; }
    private IList<ISpecification<T>> Specifications { get; }

    public void Add(T someObject)
    {
        // #4 We validate the incoming object against all injected 
        // specifications. If the incoming object is satisfied by all
        // specifications, the object is persisted using the believer
        // repository!
        if(Specifications.All(spec => spec.IsSatisfiedBy(domainObject)))
        {
            BelieverRepository.Add(someObject);
        }
        else
        {
            //  NOTE: This is an oversimplification for the sake of this sample. 
            // Actually you wouldn't throw an exception, but you would return
            // unpassed specifications somehow.
            throw new InvalidOperationException("Given object could not fulfill its specifications!");
        }
    }
}

// #5 Here's the believer repository. In our sample, we'll implement a
// repository coupled to Entity Framework OR/M as the data mapping layer.
public abstract class EntityFrameworkRepository<T> : IRepository<T>
{
    public EntityFrameworkRepository(DbSet<T> dbSet)
    {
        DbSet = dbSet;
    }

    private DbSet<T> DbSet { get; }

    public void Add(T someObject)
    {
        // This is an oversimplification for the sake of this sample.
        // Here you could also implement everything that should be 
        // coupled to Entity Framework OR/M to add objects and perform
        // whatever check, transaction or any other operation that you should
        // be required here.
        DbSet.Add(someObject);
    }
}

public sealed class CustomerService
{
    // We inject an implementation of customer repository interface.
    // The so-called implementation would be a derived class of 
    // AgnosticRepository<T>
    public CustomerService(ICustomerRepository customerRepository)
    {
    	CustomerRepository = customerRepository;
    }
    
    private ICustomerRepository CustomerRepository { get; }
    
    public Customer Create()
    {
    	Customer customer = new Customer();
        
    	CustomerRepository.Add(customer);
        
        return customer;
    }
}