Accessing properties through Generic type parameter

Question

I\'m trying to create a generic repository for my models. Currently i\'ve 3 different models which have no relationship between them. (Contacts, Notes, Reminders).

Answer 1

Interface solution

If you can add an interface to your object you can use that. For example you could define:

 public interface IName
 {
   string Name { get; }
 }

Then your repository could be declared as:

class Repository<T> where T:class, IName
{
  public IQueryable<T> SearchExact(string keyword)  
  {  
    return db.GetTable<T>().Where(i => i.Name == keyword);
  }
}  

Alternate interface solution

Alternatively you could put the "where" on your SearchExact method by using a second generic parameter:

class Repository<T> where T:class
{  
  public IQueryable<T> SearchExact<U>(string keyword) where U: T,IName
  {  
    return db.GetTable<U>().Where(i => i.Name == keyword);
  }
}  

This allows the Repository class to be used with objects that don't implement IName, whereas the SearchExact method can only be used with objects that implement IName.

Reflection solution

If you can't add an IName-like interface to your objects, you can use reflection instead:

class Repository<T> where T:class
{
  static PropertyInfo _nameProperty = typeof(T).GetProperty("Name");

  public IQueryable<T> SearchExact(string keyword)
  {
    return db.GetTable<T>().Where(i => (string)_nameProperty.GetValue(i) == keyword);
  }
}

This is slower than using an interface, but sometimes it is the only way.

More notes on interface solution and why you might use it

In your comment you mention that you can't use an interface but don't explain why. You say "Nothing in common is present in the three models. So i think making an interface out of them is not possible." From your question I understood that all three models have a "Name" property. In that case, it is possible to implement an interface on all three. Just implement the interface as shown and ", IName" to each of your three class definitions. This will give you the best performance for both local queries and SQL generation.

Even if the properties in question are not all called "Name", you can still use the nterface solution by adding a "Name" property to each and having its getter and setter access the other property.

Expression solution

If the IName solution won't work and you need the SQL conversion to work, you can do this by building your LINQ query using Expressions. This more work and is significantly less efficient for local use but will convert to SQL well. The code would be something like this:

class Repository<T> where T:Class
{
  public IQueryable<T> SearchExact(string keyword,
                                   Expression<Func<T,string>> getNameExpression)
  {
    var param = Expression.Parameter(typeof(T), "i");
    return db.GetTable<T>().Where(
                Expression.Lambda<Func<T,bool>>(
                  Expression.Equal(
                    Expression.Invoke(
                      Expression.Constant(getNameExpression),
                      param),
                    Expression.Constant(keyword),
                  param));
  }
}

and it would be called thusly:

repository.SearchExact("Text To Find", i => i.Name)

Answer 2

Ray's method is quite good, and if you have the ability to add an interface definitely the superior however if for some reason you are unable to add an interface to these classes (Part of a class library you can't edit or something) then you could also consider passing a Func in which could tell it how to get the name.

EG:

class Repository<T>
{  
  public IQueryable<T> SearchExact(string keyword, Func<T, string> getSearchField)  
  {  
    return db.GetTable<T>().Where(i => getSearchField(i) == keyword);
  }
}

You'd then have to call it as:

var filteredList = _contactRepository.SearchExact(keyword, cr => cr.Name).ToList();

Other than these two options you could always look into using reflection to access the Name property without any interface, but this has the downside that there's no compile-time check that makes sure the classes you're passing actually DO have a Name property and also has the side-effect that the LINQ will not be translated to SQL and the filtering will happen in .NET (Meaning the SQL server could get hit more than is needed).

You could also use a Dynamic LINQ query to achieve this SQL-side effect, but it has the same non type-safe issues listed above.