是否有使用实体框架将同一接口的两个实体合并的解决方法？

Question

I have a search model class that searches different entity sets with the entity itself implementing a IAssignable interface. The code looks like this.

public void Search()
    {
        List<T> lessons = new List<T>();
        List<T> courses = new List<T>();

        if (ShowLessons)
            lessons = db.Set<Lesson>()
                .Where(IAssignableExtensions.SearchPredicate(q))
                .Select(LessonMapping).ToList();
        if (ShowCourses)
            courses = db.Set<Course>()
                .Where(IAssignableExtensions.SearchPredicate(q))
                .Select(CourseMapping).ToList();
        Results = lessons.Union(courses).ToList<T>();
    }

The static extension is irrelevant, it just searched based on the query. I would prefer to bust this into it's own rather than static extension but eh. Now this works as expected. I am pulling to memory two datasets, lessons and courses, I am unioning them into a IEnumerable of a generic type based on teh Course Mapping or Lesson Mapping Expressions.

public Expression<Func<IAssignable, T>> LessonMapping { get; set; }
        public Expression<Func<IAssignable, T>> CourseMapping { get; set; }

The problem is when I want to do any type of paging. As you can see the lessons and courses are searched, brought into memory and then unioned and returned. If I do any paging using an IPagedList for example, it is bringing back ALL lessons and courses then it is only using a subset of the total data in the list for the pages.

If Entity Framework supported interfaces I would just do a cast on the interface and union right at the db call. I haven't changed this code yet but I feel I might have to create a custom stored procedure or use the Query call on the datacontext, but if I use a stored procedure I have to make sure to update it on any changes to the domain, and if I use the Query I have to re-jig the selects, interfaces and still have to worry about inline sql...

Anyone have any ideas?

UPDATE The solution that I ended up using after thinking about Erik's solution was to just use a projected object that implemented IAssignable.

public class SomeProjection : IAssignable
{
public int ID { get; set; }
public string Name { get; set; }
public string Description {get;set;}
public string Privacy {get;set;}
    }

And then used it within the union call queryable

    Results = db.Set<Lesson>().Select(p => new SomeProjection() { Privacy = p.Privacy, ID = p.ID, Name = p.Name, Description = p.Description })
        .Union(db.Set<Course>().Select(p => new SomeProjection() { Privacy = p.Privacy, ID = p.ID, Name = p.Name, Description = p.Description }))
        .Where(IAssignableExtensions.SearchPredicate(q))
            .Select(Mapping).ToList<T>();

Answer 1

If Entity Framework supported interfaces I would just do a cast on the interface and union right at the db call.

It has nothing to do with what Entity Framework supports. If you create an interface, it is independent of the SQL technology in the back end and you want EF to somehow magically select properties based on an interface with no mappings or configuration? Not going to happen.

Instead you could simply use inheritance if there are some properties that are the same between objects , then you don't even need to union them, unless you are where-ing on properties that don't exist between both.