Is there something analogous on NHibernate regarding Entity Framework's navigation property?

Is there something analogous on NHibernate regarding Entity Framework's navigation property? For example, instead of:

s.Save(new Product { Category = s.Get<Category>("FD"), Name = "Pizza" });

I wish I could write:

s.Save(new Product { CategoryId = "FD", Name = "Pizza" });

Can I inform NHibernate not to use the Product's Category property as a mechanism to save the Product's category? I want to use CategoryId instead(Read: I don't want to use DTO). Enti开发者_运维百科ty Framework seems able to facilitate avoiding DTO patterns altogether, while at the same time offering the full benefit of ORM(can avoid joins using navigation properties). I want the EF's offering the best of both worlds(lean mechanism for saving objects, i.e. no need to retrieve the property's object) and navigation mechanism for querying stuff

Sample from EF: http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4-1-code-first-walkthrough.aspx

public class Category
{
    public virtual string CategoryId { get; set; }
    public virtual string Name { get; set; }

    public virtual IList<Product> Products { get; set; }
}

public class Product
{
    public virtual int ProductId { get; set; }
    public virtual string Name { get; set; }
    public virtual string CategoryId { get; set; }

    public virtual Category Category { get; set; }
}

[UPDATE]

Regarding James answer, I tried seeing the NHibernate's actions in SQL Server Profiler.

// this act didn't hit the Category table from the database
var c = s.Load<Category>("FD"); 
// neither this hit the Category table from the database
var px = new Product { Category = c, Name = "Pizza" }; 
// this too, neither hit the Category table from the database
s.Save(px); 

Only when you actually access the Category object that NHibernate will hit the database

Console.WriteLine("{0} {1}", c.CategoryId, c.Name);

If I understand your question, you want to save a Product with a Category without hitting the database to load the Category object. NHibernate absolutely supports this and you almost have the right code. Here is how you do it in NHibernate:

s.Save(new Product { Category = s.Load<Category>("FD"), Name = "Pizza" });

This will not hit the database to fetch the actual Category, but it will simply save a Product with the correct Category.Id. Note that you don't need (and I would recommend getting rid of Product.CategoryId).

Now why does this work with session.Load(), but not session.Get()... With session.Get(), NHibernate has to return the object or null. In .NET, there is no way for an object to replace itself with null after the fact. So NHibernate is forced to go to the database (or L1 cache) to verify that the "FD" Category actually exists. If it exists, it returns an object. If not, it must return null.

Let's look at session.Load(). If the object is not present in the database, it throws an exception. So NHibernate can return a proxy object from session.Load() and delay actually hitting the database. When you actually access the object, NHibernate will check the database and can throw an exception at that point if the object doesn't exist. In this case, we're saving a Product to the database. All NHibernate needs is the Category's PK, which it has in the proxy. So it doesn't have to query the database for the Category object. NHibernate never actually needs to hydrate an actual Category object to satisfy the save request.