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
{
public ICollection<Book> Books {get; set;}
}
// Want
public class Shelf
{
public IQueryable<Book> Books {get;set;}
}
What I want to accomplish is to return a collection that is IQueryable so that I can run paging and filtering off of the collection directly from the the parent.
var shelf = shelfRepository.Get(1);
var filtered = from book in shelf.Books
where book.Name == "The Great Gatsby"
select book;
I want to have that query executed specifically by NHibernate and not a get all to load a whole collection and then parse it in memory (which is what currently happens when I use ICollection).
The reasoning behind this is that my collection could be huge, tens of thousands of records, and a get all query could bash my database.
I would like to do this implicitly so that when NHibernate sees an IQueryable on my class it knows what to do.
I have looked at NHibernate's LINQ provider and currently I am making the decision to take large collections and split them into their own repository so that I can make explicit calls for filtering and paging.
LINQ To SQL offers something similar to what I'm talking about.
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<Shelf>(id);
var books = session.FilterCollection(shelf.Books, "where Name = :title").SetString("title", "The Great Gatsby").List<Book>();
There are a problem with that, however:
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.
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<Book> FindBooks() {
return Resolver.Get<ISession>().Linq<Book>().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<Book> FindBooks() {
return Resolver.Get<IRepository<Book>>().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.
I tend to think like this:
Aggregate roots are boundaries of consistency, so if shelf needs to enforce some sort of consistency policies on the books it contains, then it should be an aggregate root.
And in such case it should hold a set/collection of books.
If you don't need to enforce consistency in any way from shelf to books, then I'd consider to remove the set/collection property and move those queries into a repository instead.
Also, since pagination and filtering most likely don't have anything to do with your domain logic, it is most likely for presentation.
Then I'd consider to make some special view for it instead of adding presentation facillities to my repositories.
e.g.
var result = Queries.FindBooksByShelf(shelfId,pageSize);
Such query could return projections and/or be optimized as plain SQL etc.
They are most likely specific for a certain view or report in your GUI.
This way your domain will focus on domain concepts only.
Perhaps you should give Nhibernate Linq a try. It allows you use the IQueryable and do things like:
Session.Linq<Book>().Where(b => b.Name == "The Great Gatsby");
Related
I'd like to know whether, when defining my interface, I should prefer IQueryable over List for groups of objects. Or perhaps IEnumerable is better, since IEnumerable types can be cast to IQueryable to be used with LINQ.
I was looking at a course online and it was dealing with EntityFramework, for which it is best to use IQueryable since LINQ uses it (okay there's more to it than that but probably not important right now).
The code below was used, and it got me thinking if I should be specifying IQueryable instead of List for my groups of objects.
namespace eManager.Domain
{
public interface IDepartmentDataSource
{
IQueryable<Employee> Employees { get; }
IQueryable<Department> Departments { get; }
}
If I were building an interface for a service that calls the repository to get Employees, I would usually specify
List <Employees>
but is this best practice? Would IQueryable give more flexibility to classes that implement my interface? What about the overhead of having to import LINQ if they don't need it (say they only want a List)? Should I use IEnumerable over both of these?
The IQueryable interface is in effect a query on Entity Framework that is not yet executed. When you call ToList(), First() or FirstOrDefault() etc. on IQueryable Entity Framework will construct the SQL query and query the database.
IEnumerable on the other hand is 'just' an enumerator on a collection. You can use it to filter the collection but you'd use LINQ to Objects. Entity Framework doesn't come into play here.
To answer your question: it depends. If you want the clients of your repository to be able to further customize the queries they can execute you should expose IQueryable, but if you want full control in your repository on how the database is queried you could use IEnumerable.
I prefer to use IEnumerable, because that doesn't leak the use of Entity Framework throughout the application. The repository is responsible for database access. It is also easier to make LINQ to EF optimizations, because the queries are only in the repository.
What I usually do is make the repositories return IQueryable. Then in the BL I specify either IEnumerable or IQueryble. It is important to know the main differences between IQueryble and IEnumerable.
Lets say you fetch data into IEnumerable
IEnumerable employees=this.repository.GetAll();
Now let's say this specific function require only employees with age over 21 and the others are not needed at all.
You would do:
employees.Where(a=>a.Age>21)
In this case the original query will be loaded in the memory and then the Where will be applied.
Now lets say you change the function to fetch the data into IQueryable
IQueryable employees=this.repository.GetAll();
employees.Where(a=>a.Age>21)
This time when you modify the query with the Where clause, the whole query will be executed in the database (if possible) and you will only get employees with age over 21 from the database.
In the IEnumerable case you will get all the employees from the database and then they will get filtered in memory to satisfy the where condition.
Use IEnumerable, IList or something else?
If you know what operations will be executed on the collection you can easily choose which interface to use. Basically if you will only iterate over the collection you would use IEnumerable. If you would do more operations you need to choose the appropriate interface. There are good videos of .NET collections in pluralsight.
I have an ASP.NET MVC application coded with C#. The application is structured this way:
Controller
Repository
LINQ to Entities (Entity Framework)
View
I use the Repository (_ProductRep) to query the LINQ to Entities and give to the Controller actual entities or List<T>, not IQueriables<T>.
I would like to have some help about a situation where I have more than a doubt. I have the following code:
List<Monthly_Report> lproduct_monthlyReport = _ProductRep.GetArchiveReport(product.Prod_ID, lmonth, lyear);
After I get this lproduct_monthlyReport I need to query it inside a foreach and get a specific record. Currently I implemented the solution like this:
foreach (var item in litemList)
{
var lproductItem_monthlyReport = lproduct_monthlyReport.Single(m => m.Item_ID == item.Item_ID);
// Other code
}
Where litemList is the list of all the possible items a product can have.
I wanted to know whether this solution sensibly increase the coupling (and violates the law of Demeter) or it is acceptable because I am actually querying a List<T> and not an IQueriable<T>. Correct me if I am wrong, but I guess that since the List does not need to access the EF DataContext, there is no coupling between Controller and EF.
In case I am wrong, the only solution I can think about is to substitute the query with a Repository method (that still I have to implement):
var lproductItem_monthlyReport_ProductRep.GetArchiveReport(product.Prod_ID, lmonth, lyear, item.Item_ID);
with this solution however the Repository makes one query with 4 conditions every loop cycle whilst in the previous solution the repository was making a query with just one conditions.
May you please enlighten me on this issue? Thanks.
PS: I need both variables lproduct_monthlyReport and lproductItem_monthlyReport inside the loop, I cannot just use one of them
PPS: I know that I should have a Business Service Layer between Controller and Repository, it is my next step.
Returning Lists from your repository will give you awful performance, because you lose the deferred execution behaviour. Basically your repository will retrieve every single record, and not related entities, into memory, and turn them into a List, which then gets processed in memory. If you want to access a related entity, it'll need another database hit. If you stick with IEnumerable (or IQueryable), then you are hiding the nuances of the entity framework behaviour from the client, but still getting the advantages like lazy loading and deferred execution.
Ignoring the specifics of your Repository for now, if you do this:
List<Product> products = MyEntities.Products.ToList();
Product product1 = products.Single(p => p.Id = 1);
it will perform much worse than this:
IEnumerable<Product> products = MyEntities.Products;
Product product1 = products.Single(p => p.Id = 1);
The first one will perform a SELECT in the database with no WHERE clauses, then instantiate .Net objects for every result, then query that in-memory list. The second will do nothing until you access a property on product1 and will at that point issue a database command to just retrieve the 1 product, and only instantiate that 1 product.
The difference between the 2 may not be noticeable with small data sets, but as the data set gets larger this will get worse and worse. Throw in a connected entity (or worse still entity collection), and you'll get potentially thousands of database hits, where if you stuck with IEnumerable you'd get 1.
I would probably have function like this GetArchiveReport(int prodID, int lmonth, int lyear, IEnumerable<int> itemIDs) that would do a itemIDs.Contains(tbl.ID) inside your query
var SelectedReports = _ProductRep.GetArchiveReport(product.Prod_ID, lmonth, lyear, litemList.Select(item => item.Item_ID));
foreach(var prodItem in SelectedReports)
{
//Do code
}
I have a LINQ to Entities query (using EF 4) that has some pretty complicated set-based filtering going on. The code compiles just fine, but when I try to run it, I get the following error:
Unable to create a constant value of type 'ITextEntity'. Only primitive types ('such as Int32, String, and Guid') are supported in this context.
Now for the code. I have an interface that looks like this:
public interface ITextEntity
{
int ID { get; set; }
string TextValue { get; set; }
EntityCollection<Product> Products { get; set; }
}
The idea is that these "Text Entities" represent lookup tables storing properties of Product. If Products have a color, all red Products will contain a Color entity with TextValue = "Red", and there will be a Color entity decorated with this interface:
public partial class Color : ITextEntity
{
//ID, TextValue, and Products implemented in EF-generated code
}
ITextEntities may have 1:N or N:N relationships back to Product.
I have a nested collection (actually a List<IEnumerable<ITextEntity>>) which contains sets of different entities implementing the ITextEntity interface. I want to use these sets to filter a sequence of Products in a semi-inclusive fashion. Here's the code:
List<IEnumerable<ITextEntity>> InclusiveFilters;
IQueryable<Product> Products;
//...snip...
Products = Products.Where(prod =>
InclusiveFilters.All(filter =>
filter.Any(iTextEnt =>
iTextEnt.Product.Contains(prod)
)
)
);
So what I'm trying to do is this:
I have a set, Products, that I want to filter.
For each of several types that implement ITextEntity, there's a
set S of entities of that type.
Each object O has a set O.P of products.
For each Product prod in Products,
for each set S,
for at least one O in S,
O.P must contain prod. If not, remove prod from Products.
As you can see, this is pretty complicated.
I have the feeling that this is caused by LINQ not being able to work with the ITextEntity type, rather than a problem with my set operations. However, the complexity of the above is making this difficult to work with, and difficult to find a non-LINQ alternative. It's going to get pretty ugly if I can't use LINQ.
I found an MSDN page and a Stack Overflow thread discussing similar exceptions, but neither was much help. Another SO thread aims a finger at my use of the Contains method, but because of the complexity here, I haven't had much luck trying to replace it with the BuildOrExpression method. I doubt BuildOrExpression will work anyway, since this is EF 4 and Contains is supposed to be supported.
So I'm rather stuck here. Can anyone advise?
EDIT: This question was answered in Aug 2010, but I've come back to clean up the title and description.
You're implicitly casting to ITextEntity. But ITextEntity is not part of your entity data model, so the EF doesn't know how to translate its members into SQL. Contains is supported, but only with primitive or entity types. Also, you use IEnumerable, which also prevents translation to SQL; you need IQueryable to be convertable to SQL.
So if you remove the interface reference and IEnumerable, you should be able to execute the query on the DB server. Otherwise you have to go into L2O (with, e.g., AsEnumerable()).
I have a list of products coming from a repository. Simple enough. Now I want to add filtering and sorting. Sorting could happen outside of the repository since there are no efficiency gains doing them inside the repository (guess). I couldn't imagine doing filtering outside of the repository since we only want to load records we care about. I would think you would want to create a filter delegate and pass it to the repository.
The below code is pseudo C# code. What would functioning code look like to sort / filter?
The process below is really centered around passing delegates to the repository to filter:
Product myProduct = Repo.GetProducts( filter );
(if this were MS MVC, this code would exist in the controller):
Setup a filter:
//TODO: Need filter class definition
var filter = new Filter(); // made up object class for now
filter.AddCondition( field, operator, value); // do this for each filter condition
filter.AddCondition( Product.Name, contains, "Hammer"); // Product.Name ?? (Example)
Product myProducts = Repo.GetProducts( filter ); // the Product call **FILTER**
Setup a sort:
// TODO: Need sort class definition
var sort = new Sort(); // another made up object class for now
sort.AddOrder( field, priority, sequenceUp) // Sequence enum is ascending/descending
sort.AddOrder( Product.Name, 1, ascending) // (Example) **SORT**
myProducts.AddSort(sort);
Return a view model:
// Next part strips off unnecessary fields for view (Presentation model)
// So we are not sending a huge data model to the view (hopefully good)
// TODO: Replace string with Service? function to extract a miniProduct from Product
MiniProduct myMinis = MakeMiniProductsFrom( myProducts); // Service?
// Determine response type (XML, JSON, HTML View) and return appropriate data
// use "x-requested-by" as per Rob Conery noted below
if (Request.IsAjaxRequest()) return Json(myMinis);
else return View(myMinis);
As you can see, this code needs some help. I am really looking for sort and filter class code that could make this work, or links to outside sources. I assume sorting and filtering are a standard practice within DDD and design patterns, thus the question. Assume Product is a plain old e-commerce product ;) Rob Conery's Ajax notes are here
Thanks.
Ideally, you'll probably want to do the sorting and the filtering inside the repository. This is particularly important if you're loading large collections, since the DB will most likely be able to sort more efficiently than you can do, and return the sorted results directly.
The IQueryable<T> interface is designed to handle this cleanly - it's the basis for Entity Framework, LINQ to SQL, and other databases with a LINQ provider. The nice thing about trying to support (at least at some level) IQueryable<T> is this lets you use your repository in a very standard way. For example, your pseudocode, using IQueryable<T>, might look more like:
IList<Product> myProducts = Repo.Products.Where( p => p.Category == theCategoryToFind ).OrderBy( p => p.Name );
Or, optionally, just:
var products = from p in Repo.Products
where p.Category == theCategory
order by p.Name
select p;
I recommend looking at how some of the LINQ-oriented data access technologies work - there are quite a few open source options, such as Subsonic (as well as many commercial options) that may provide clues as to how you can better design this for usability.
Suppose I have
public class Product: Entity
{
public IList<Item> Items { get; set; }
}
Suppose I want to find an item with max something... I can add the method Product.GetMaxItemSmth() and do it with Linq (from i in Items select i.smth).Max()) or with a manual loop or whatever. Now, the problem is that this will load the full collection into memory.
The correct solution will be to do a specific DB query, but domain entities do not have access to repositories, right? So either I do
productRepository.GetMaxItemSmth(product)
(which is ugly, no?), or even if entities have access to repositories, I use IProductRepository from entity
product.GetMaxItemSmth() { return Service.GetRepository<IProductRepository>().GetMaxItemSmth(); }
which is also ugly and is a duplication of code. I can even go fancy and do an extension
public static IList<Item> GetMaxItemSmth(this Product product)
{
return Service.GetRepository<IProductRepository>().GetMaxItemSmth();
}
which is better only because it doesn't really clutter the entity with repository... but still does method duplication.
Now, this is the problem of whether to use product.GetMaxItemSmth() or productRepository.GetMaxItemSmth(product)... again. Did I miss something in DDD? What is the correct way here? Just use productRepository.GetMaxItemSmth(product)? Is this what everyone uses and are happy with?
I just don't feel it is right... if I can't access a product's Items from the product itself, why do I need this collection in Product at all??? And then, can Product do anything useful if it can't use specific queries and access its collections without performance hits?
Of course, I can use a less efficient way and never mind, and when it's slow I'll inject repository calls into entities as an optimization... but even this doesn't sound right, does it?
One thing to mention, maybe it's not quite DDD... but I need IList in Product in order to get my DB schema generated with Fluent NHibernate. Feel free to answer in pure DDD context, though.
UPDATE: a very interesting option is described here: http://devlicio.us/blogs/billy_mccafferty/archive/2007/12/03/custom-collections-with-nhibernate-part-i-the-basics.aspx, not only to deal with DB-related collection queries, but also can help with collection access control.
Having an Items collection and having GetXXX() methods are both correct.
To be pure, your Entities shouldn't have direct access to Repositories. However, they can have an indirect reference via a Query Specification. Check out page 229 of Eric Evans' book. Something like this:
public class Product
{
public IList<Item> Items {get;}
public int GetMaxItemSmth()
{
return new ProductItemQuerySpecifications().GetMaxSomething(this);
}
}
public class ProductItemQuerySpecifications()
{
public int GetMaxSomething(product)
{
var respository = MyContainer.Resolve<IProductRespository>();
return respository.GetMaxSomething(product);
}
}
How you get a reference to the Repository is your choice (DI, Service Locator, etc). Whilst this removes the direct reference between Entity and Respository, it doesn't reduce the LoC.
Generally, I'd only introduce it early if I knew that the number of GetXXX() methods will cause problems in the future. Otherwise, I'd leave it for a future refactoring exercise.
I believe in terms of DDD, whenever you are having problems like this, you should first ask yourself if your entity was designed properly.
If you say that Product has a list of Items. You are saying that Items is a part of the Product aggregate. That means that, if you perform data changes on the Product, you are changing the items too. In this case, your Product and it's items are required to be transactionally consistent. That means that changes to one or another should always cascade over the entire Product aggregate, and the change should be ATOMIC. Meaning that, if you changed the Product's name and the name of one of it's Items and if the database commit of the Item's name works, but fails on the Product's name, the Item's name should be rolled back.
This is the fact that Aggregates should represent consistency boundaries, not compositional convenience.
If it does not make sense in your domain to require changes on Items and changes on the Product to be transactionally consistent, then Product should not hold a reference to the Items.
You are still allowed to model the relationship between Product and items, you just shouldn't have a direct reference. Instead, you want to have an indirect reference, that is, Product will have a list of Item Ids.
The choice between having a direct reference and an indirect reference should be based first on the question of transactional consistency. Once you have answered that, if it seemed that you needed the transactional consistency, you must then further ask if it could lead to scalability and performance issues.
If you have too many items for too many products, this could scale and perform badly. In that case, you should consider eventual consistency. This is when you still only have an indirect reference from Product to items, but with some other mechanism, you guarantee that at some future point in time (hopefully as soon as possible), the Product and the Items will be in a consistent state. The example would be that, as Items balances are changed, the Products total balance increases, while each item is being one by one altered, the Product might not exactly have the right Total Balance, but as soon as all items will have finished changing, the Product will update itself to reflect the new Total Balance and thus return to a consistent state.
That last choice is harder to make, you have to determine if it is acceptable to have eventual consistency in order to avoid the scalability and performance problems, or if the cost is too high and you'd rather have transactional consistency and live with the scalability and performance issues.
Now, once you have indirect references to Items, how do you perform GetMaxItemSmth()?
In this case, I believe the best way is to use the double dispatch pattern. You create an ItemProcessor class:
public class ItemProcessor
{
private readonly IItemRepository _itemRepo;
public ItemProcessor(IItemRepository itemRepo)
{
_itemRepo = itemRepo;
}
public Item GetMaxItemSmth(Product product)
{
// Here you are free to implement the logic as performant as possible, or as slowly
// as you want.
// Slow version
//Item maxItem = _itemRepo.GetById(product.Items[0]);
//for(int i = 1; i < product.Items.Length; i++)
//{
// Item item = _itemRepo.GetById(product.Items[i]);
// if(item > maxItem) maxItem = item;
//}
//Fast version
Item maxItem = _itemRepo.GetMaxItemSmth();
return maxItem;
}
}
And it's corresponding interface:
public interface IItemProcessor
{
Item GetMaxItemSmth(Product product);
}
Which will be responsible for performing the logic you need that involves working with both your Product data and other related entities data. Or this could host any kind of complicated logic that spans multiple entities and don't quite fit in on any one entity per say, because of how it requires data that span multiple entities.
Than, on your Product entity you add:
public class Product
{
private List<string> _items; // indirect reference to the Items Product is associated with
public List<string> Items
{
get
{
return _items;
}
}
public Product(List<string> items)
{
_items = items;
}
public Item GetMaxItemSmth(IItemProcessor itemProcessor)
{
return itemProcessor.GetMaxItemSmth(this);
}
}
NOTE:
If you only need to query the Max items and get a value back, not an Entity, you should bypass this method altogether. Create an IFinder that has a GetMaxItemSmth that returns your specialised read model. It's ok to have a separate model only for querying, and a set of Finder classes that perform specialized queries to retrieve such specialized read model. As you must remember, Aggregates only exist for the purpose of data change. Repositories only work on Aggregates. Therefore, if no data change, no need for either Aggregates or Repositories.
(Disclaimer, I am just starting to get a grasp on DDD. or at least believe doing it :) )
I will second Mark on this one and emphasize 2 point that took me some times to realize.
Think about your object in term of aggregates, which lead to
The point is that either you load the children together with the parent or you load them separately
The difficult part is to think about the aggregate for your problem at hand and not to focus the DB structure supporting it.
An example that emphasizes this point i customer.Orders. Do you really need all the orders of your customer for adding a new order? usually not. what if she has 1 millin of them?
You might need something like OutstandingAmount or AmountBuyedLastMonth in order to fulfill some scenarios like "AcceptNewOrder" or ApplyCustomerCareProgram.
Is the product the real aggregate root for your sceanrio?
What if Product is not an Aggregate Root?
i.e. are you going to manipulate the item or the product?
If it is the product, do you need the ItemWithMaxSomething or do you need MaxSomethingOfItemsInProduct?
Another myth: PI means You don't need to think about the DB
Given that you really need the item with maxSomething in your scenario, then you need to know what it means in terms of database operation in order to choose the right implementation, either through a service or a property.
For example if a product has a huge number of items, a solution might be to have the ID of the Item recorded with the product in the db instead of iterating over the all list.
The difficult part for me in DDD is to define the right aggregates. I feel more and more that if I need to rely on lazy loading then I might have overseen some context boundary.
hope this helps :)
I think that this is a difficult question that has no hard and fast answer.
A key to one answer is to analyze Aggregates and Associations as discussed in Domain-Driven Design. The point is that either you load the children together with the parent or you load them separately.
When you load them together with the parent (Product in your example), the parent controls all access to the children, including retrieval and write operations. A corrolary to this is that there must be no repository for the children - data access is managed by the parent's repository.
So to answer one of your questions: "why do I need this collection in Product at all?" Maybe you don't, but if you do, that would mean that Items would always be loaded when you load a Product. You could implement a Max method that would simply find the Max by looking over all Items in the list. That may not be the most performant implementation, but that would be the way to do it if Product was an Aggregate Root.
What if Product is not an Aggregate Root? Well, the first thing to do is to remove the Items property from Product. You will then need some sort of Service that can retrieve the Items associated with the Product. Such a Service could also have a GetMaxItemSmth method.
Something like this:
public class ProductService
{
private readonly IItemRepository itemRepository;
public ProductService (IItemRepository itemRepository)
{
this.itemRepository = itemRepository;
}
public IEnumerable<Item> GetMaxItemSmth(Product product)
{
var max = this.itemRepository.GetMaxItemSmth(product);
// Do something interesting here
return max;
}
}
That is pretty close to your extension method, but with the notable difference that the repository should be an instance injected into the Service. Static stuff is never good for modeling purposes.
As it stands here, the ProductService is a pretty thin wrapper around the Repository itself, so it may be redundant. Often, however, it turns out to be a good place to add other interesting behavior, as I have tried to hint at with my code comment.
Another way you can solve this problem is to track it all in the aggregate root. If Product and Item are both part of the same aggregate, with Product being the root, then all access to the Items is controlled via Product. So in your AddItem method, compare the new Item to the current max item and replace it if need be. Maintain it where it's needed within Product so you don't have to run the SQL query at all. This is one reason why defining aggregates promotes encapsulation.
Remember that NHibernate is a mapper between the database and your objects. Your issue appears to me that your object model is not a viable relational model, and that's ok, but you need to embrace that.
Why not map another collection to your Product entity that uses the power of your relational model to load in an efficient manner. Am I right in assuming that the logic to select this special collection is not rocket science and could easily be implemented in filtered NHibernate mapped collection?
I know my answer has been vague, but I only understand your question in general terms. My point is that you will have problems if you treat your relational database in an object oriented manner. Tools like NHibernate exist to bridge the gap between them, not to treat them in the same way. Feel free to ask me to clarify any points I didn't make clear.
You can now do that with NHibernate 5 directly without specific code !
It won't load the whole collection into memory.
See https://github.com/nhibernate/nhibernate-core/blob/master/releasenotes.txt
Build 5.0.0
=============================
** Highlights
...
* Entities collections can be queried with .AsQueryable() Linq extension without being fully loaded.
...