将通用类型传递给通用接口

Question

I am trying to implement a totally generic CRUD API whereby any class type can be passed in and generically saved, updated etc by the context.

I have a repository that saves any model type like this:

public class Repository<T> : IRepository<T> where T : class 
    {
        private Context _db = new Context();

        public T Add(T newItem) 
        {
            var result = _db.Set<T>().Add((T)newItem);
            _db.SaveChanges();

            return result;
        }
    }

This inherits from a generic interface that implements all the "add" method:

public interface IRepository<T> where T : class
{
    T Add(T newItem);
}

I am struggling to understand why I can't pass a generic type into a new instance of the repository interface? I would ideally like something like:

var data = new Data(){
    Id = 1
};

IRepository<data.GetType()> repo = new Repository<data.GetType()>();

Thereby allowing me to pass any type into the method and generating the correct interface off the back of this.

It allows me to pass in a concrete type but that sort of defeats the object of making it generic.

Any ideas around this or explanations of why it's not possible will be greatly appreciated - thanks.

Answer 1

Trying to implement a generic repository with a generic parameter on the IRepository itself doesn't make sense because the term generic (in this case) does not refer to CLR generics but to the nature of the repository, which is the ability to work with different types of entities using the same repository instance, in contrast to repository-per-type approach (like ProductsRepository for example).

Placing the generic parameter on the methods can easily solve the problem:

public interface IRepository
{
     T GetById<T>(object id);
     IEnumerable<T> Get<T>(Expression<Func<T, bool>> criteria);
     T Add<T>(T data);
}

Possible implementation using EntityFramework would be:

public class EntityFrameworkRepository : IRepository
{
    public T GetById<T>(object id)
    {
        return this.Set<T>().Find(id);
    }

    public IEnumerable<T> Get<T>(Expression<Func<T, bool>> criteria)
    {
        return this.Set<T>().Where(criteria);
    }

    public T Add<T>(T data)
    {
        this.Set<T>().Add(data);
        return data;
    }
}

Answer 2

You've hit upon a constraint of generics (I was going to use the word "limitation", but that's wrong - it's not a limitation, quite the opposite).

Generics provide you type safety at compile-time, it allows cleaner code, but you must know the type you're working with at compile-time. If you do not know the type until run time, as it seems you don't then generics is almost certainly the wrong solution.

Library developers know this, they know you often can not or do not want to specify the type, so often they provide a non-generic equivalent. The non-generic equivalent takes a Type as a traditional parameter rather than a generic parameter.

For example, I think you're using the DbSet<T> in EntityFramework, but EntityFramework also provides a non generic DbSet .

So this line in your code:

var result = _db.Set<T>().Add((T)newItem);

Could be written as

var result = _db.Set(newItem.GetType()).Add(newItem);

Expanding this out, you could define a non-generic IRepository :

public interface IRepository
{
    object Add(object newItem);
}

And implement it as

public class Repository : IRepository
{
    private Context _db = new Context();
    private Type entityType;
    public Repository (Type entityType)
    {
        this.entityType= entityType;
    }

    public object Add(object newItem) 
    {
        var result = _db.Set(entityType).Add(newItem);
        _db.SaveChanges();

        return result;
    }
}

It will work, but you've lost all type safety, making the response from your Add method near-on useless.

All in all, once you've followed this rabbit hole I suspect you'll return to the generic solution - it's light-years ahead of the non-generic solution (Thats why generics were added!)