Given your request, you could simply not map from Department to Employees, nor have an Employees property on your department. This would mean you always have to make a database hit to find the employees of a database.
Aplogies if these code examples don't work out of the box, I'm not near a compiler at the moment
So, your department class might look like:
public class Department
{
public int Id { get; protected set; }
public string Name { get; set; }
/* Equality and GetHashCode here */
}
and your Employee would look like:
public class Employee
{
public int Id { get; protected set; }
public Name Name { get; set; }
public Department Department { get; set; }
/* Equality and GetHashCode here */
}
Any time you wanted to find Employees for a department, you've have to call:
/*...*/
session.CreateCriteria(typeof(Employee))
.Add(Restrictions.Eq("Department", department)
.List<Employee>();
Simply because your spec says "Departments have many Employees", doesn't mean you have to map it as a bi-directional association. If you can keep your associated uni-directional, you can really get your data-access to fly too.
Google "Domain Driven Design" Aggregate, or see Page 125 of Eric Evan's book on Domain Driven Design for more information
Best Answer
As you can see from the question and answer you linked, you can sort of achieve this by making relationships uni-directional. So instead of directly answering how, I'm going to ask why in hopes of getting to a better "how."
I definitely see why you would not always want collections to be eagerly fetched, and that is why NHibernate has lazy loading (and why NHibernate always lazy loads collections unless you pre-fetch). NHibernate will not actually fetch that collection until you actually ask for it. So my question is why do you want NHibernate to not load the collection when you are operating upon it? What do you want NHibernate to do when you access a child collection on your entity?
Update:
You didn't really answer my question of why (maybe I'm just being stubborn) but fine, you want control. Well the simplest way to keep NH from doing its job is to not tell it to do so in the first place (i.e. don't map it). That is, don't map the "many" (collection) end of the relationship. You can still keep the collection on your class but as long as you haven't told NHibernate to populate it by adding it to your mapping file, it never will. Then you can add a
PopulateCollectionmethod somewhere to run the NH query and store the results in that collection. You lose all the nice semantics that NHibernate provides for collections though, because it can't track changes to it; you'll have to implement your own Add and Remove methods.So, basically David Kemp's answer on the other question.