NHibernate IQueryable collection as property of root

前端 未结 3 1369
时光说笑
时光说笑 2021-02-13 12:15

I have a root object that has a property that is a collection.

For example:

I have a Shelf object that has Books.

// Now
public class Shelf 
{
    publ         


        
3条回答
  •  执笔经年
    2021-02-13 12:48

    I've been trying to come up with a solution for a similar problem.

    You can filter collections off an entity using ISession.FilterCollection. This creates an additional IQuery where you can count, page, add criteria, etc.

    So, for example (my query in FilterCollection may be a little off, but you should get the idea):

    ISession session = GetSession();
    var shelf = session.Get(id);
    var books = session.FilterCollection(shelf.Books, "where Name = :title").SetString("title", "The Great Gatsby").List();
    

    There are a problem with that, however:

    1. The consumer executing the code needs to access ISession.CreateFilter, or you need to create a method on your repository that takes in a property, a query, and your query arguments (as well as any paging or other information). Not really the sexiest thing on the planet.
    2. It's not the LINQ you wanted.

    Unfortunately, I don't think there's any way to get what you want out of the box with NHibernate. You could fake it, if you wanted to try, but they seem to fall flat to me:

    Add a method or property that under the covers returns a LINQ to NHibernate IQueryable for this shelf:

    public IQueryable FindBooks() {
      return Resolver.Get().Linq().Where(b => b.Shelf == this);
    }
    

    where someone might consume that like this:

    var shelf = ShelfRepo.Get(id);
    var books = (from book shelf.FindBooks()
                 where book.Title == "The Great Gatsby"
                 select book);
    

    Yuck! You are bleeding your persistence needs through your domain model! Maybe you could make it a little less worse by having a repository emit IQueryable, which at runtime is actually LINQ to NHibernate:

    public IQueryable FindBooks() {
      return Resolver.Get>().CreateQuery().Where(b => b.Shelf == this);
    }
    

    Still pretty blah.

    Create your own custom collection type (and potentially an IQueryable implementation) that wraps a private field of the actual books, and map NHibernate to that field. However, it may be a difficult undertaking getting that working with ISession.CreateFilter. You have to consider "discovering" the current session, converting the LINQ expression into something you can use in CreateFilter, etc. Plus, your business logic is still dependent on NHibernate.

    Nothing really satisfies at this point. Until NHibernate can do LINQ over a collection for you, it appears that you're better off just querying your Book repository normally as has already been suggested, even if it doesn't seem as sexy or optimal.

提交回复
热议问题