If you recall the unit tests that we wrote in the previous chapters, we commonly used a method named Get<T> on ISession to retrieve a persistent instance of an entity by its id. Following is relevant part of that code:

using (var transaction = session.BeginTransaction())
{
  var employee = session.Get<Employee>(id);
  transaction.Commit();
}

You might be wondering what the reason behind providing this method is. All we are doing is querying an entity by its primary key. Why not use criteria query, QueryOver, or LINQ to query entities by primary key? Well, you can use those methods when you are not querying by identifier, but if you are querying by identifier then Get<T> has some optimizations built in that make it a preferred choice over any other querying method. Even other querying methods will use Get<T> internally if they need to load an entity by identifier.

Get<T> will first check whether an entity is present in the identity map of the session, and it would then check the second level cache for existence of the entity there. If an entity is not found in both identity map and second level cache, then it issues SQL to fetch the entity from database. Do you see the difference? There is an element of optimization that Get<T> applies that other querying methods do not. If there is a chance that an entity is present in first or second level cache then you can save a database roundtrip and few CPU cycles by using Get<T>.

ISession has another method named Load<T> which is syntactically same as Get<T> with a subtle difference in how it works internally. Get<T> would go from first level cache to second level cache to database looking for the entity and if not found, it returns a null. On the other hand, Load<T> works similarly to how lazy loading works. Load<T> does not hit the database immediately. It only returns a proxy of the entity with its identity set to the one passed to it. If you try to access any other properties of the entity returned by Load<T> then actual loading of the entity from database is triggered. Because NHibernate does not check if the id that you passed to Load<T> is present in the database or not, it is possible to pass non-existing id to Load<T> and still get a proxy entity back. When NHibernate tries to load this entity from database, it figures out that there is no record in database with that id and throws NHibernate.ObjectNotFoundException.

object employeeId =null; //This is passed from some other code
var communities = Database.Session.Query<Community>()
        .First(c => c.Name == "London bikers");

var employee = Database.Session.Get<Employee>(employeeId);
communities.AddMember(employee);