Zugriff auf Eigenschaften über generischen Typparameter

Question

Ich versuche, ein generisches Repository für meine Modelle zu erstellen. Derzeit habe ich 3 verschiedene Modelle, die keine Beziehung zwischen ihnen haben. (Kontakte, Notizen, Erinnerungen).

class Repository<T> where T:class 
{ 
    public IQueryable<T> SearchExact(string keyword) 
    { 
     //Is there a way i can make the below line generic 
     //return db.ContactModels.Where(i => i.Name == keyword)   
     //I also tried db.GetTable<T>().Where(i => i.Name == keyword) 
     //But the variable i doesn't have the Name property since it would know it only in the runtime 
     //db also has a method ITable GetTable(Type modelType) but don't think if that would help me 
    } 
} 

In MainViewModel, nenne ich die Suchmethode wie folgt aus:

Repository<ContactModel> _contactRepository = new Repository<ContactModel>(); 

public void Search(string keyword) 
{ 
    var filteredList = _contactRepository.SearchExact(keyword).ToList(); 
} 

Lösung:

schließlich mit Ray Dynamic Expression Lösung ging:

public IQueryable<TModel> SearchExact(string searchKeyword, string columnName) 
{ 
    ParameterExpression param = Expression.Parameter(typeof(TModel), "i"); 
    Expression left = Expression.Property(param, typeof(TModel).GetProperty(columnName)); 
    Expression right = Expression.Constant(searchKeyword); 
    Expression expr = Expression.Equal(left, right); 
} 

query = db.GetTable<TModel>().Where(Expression.Lambda<Func<TModel, bool>>(expr, param)); 

Answer 1

Schnittstelle Lösung

Wenn Sie Ihrem Objekt eine Schnittstelle hinzufügen können, können Sie das verwenden. Zum Beispiel könnten Sie definieren:

public interface IName 
{ 
    string Name { get; } 
} 

Dann könnte Ihr Repository deklariert werden als:

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

Alternate-Interface-Lösung

Alternativ Sie die "where" auf SearchExact Methode setzen könnte durch Verwenden eines zweiten generischen Parameters:

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); 
    } 
} 

Dadurch kann die Repository-Klasse mit Objekten verwendet werden, die IName nicht implementieren, während die SearchExact-Methode nur mit Objekten verwendet werden kann, die IName implementieren.

Reflection Lösung

Wenn Sie keine Iname-ähnliche Oberfläche, um Ihre Objekte hinzufügen können, können Sie Reflexion statt:

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); 
    } 
} 

Dies ist langsamer als eine Schnittstelle verwendet, aber manchmal Es ist der einzige Weg.

Weitere Hinweise zur Interface-Lösung und warum Sie es vielleicht

In Ihrem Kommentar verwenden Sie erwähnen, dass Sie nicht über eine Schnittstelle verwenden können, aber nicht erklären, warum. Du sagst: "Nichts ist in den drei Modellen vorhanden. Daher denke ich, dass es unmöglich ist, eine Schnittstelle daraus zu machen." Aus Ihrer Frage habe ich verstanden, dass alle drei Modelle eine "Name" -Eigenschaft haben. In diesem Fall ist es ist möglich, eine Schnittstelle auf allen drei zu implementieren. Implementieren Sie einfach die Schnittstelle wie gezeigt und ", IName" zu jeder Ihrer drei Klassendefinitionen. Dadurch erhalten Sie die beste Leistung für lokale Abfragen und SQL-Generierung.

Auch wenn die fraglichen Eigenschaften nicht alle als "Name" bezeichnet werden, können Sie die nterface-Lösung dennoch verwenden, indem Sie jeder Eigenschaft eine "Name" -Eigenschaft hinzufügen und deren Getter und Setter auf die andere Eigenschaft zugreifen.

Expression Lösung

Wenn die Iname Lösung nicht funktionieren, und Sie müssen die SQL-Umwandlung zu arbeiten, können Sie dies tun, indem Sie Ihre LINQ-Abfrage mit Ausdrücken zu bauen. Dies ist mehr Arbeit und ist für die lokale Verwendung deutlich weniger effizient, wird aber gut zu SQL konvertieren. Der Code würde wie folgt sein:

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)); 
    } 
} 

und es würde thusly genannt werden:

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

Answer 2

Rays Methode ist recht gut, und wenn Sie die Möglichkeit haben, eine Schnittstelle auf jeden Fall die bessere hinzuzufügen jedoch, wenn Aus irgendeinem Grund können Sie keine Schnittstelle zu diesen Klassen hinzufügen (Teil einer Klassenbibliothek, die Sie nicht bearbeiten können oder etwas). Sie könnten auch in Betracht ziehen, einen Func zu übergeben, der ihm sagt, wie er den Namen erhält.

Beispiel:

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

Sie würden dann rufen müssen, um es als:

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

Anders als diese beiden Optionen, die Sie immer in die Reflexion aussehen könnte die Eigenschaft Name ohne Schnittstelle für den Zugriff auf , aber das hat den Nachteil, dass es keine Kompilierzeitprüfung gibt, die sicherstellt, dass die Klassen, die Sie übergeben, tatsächlich eine Name-Eigenschaft haben und den Nebeneffekt haben, dass LINQ nicht in SQL übersetzt wird und die Filterung stattfindet .NET (Bedeutung der SQL-Server konnte getroffen werden m Erz als benötigt wird).

Sie können auch eine dynamische LINQ-Abfrage verwenden, um diesen SQL-Side-Effekt zu erzielen, aber es hat dieselben nicht typsicheren Probleme, die oben aufgeführt sind.