NHibernate: Many-to-One - *Must* You Load the Parent Object? - nhibernate

Question

Assume the following entity classes:
public class Player
{
public virtual int ID { get; set; }
public virtual string Name { get; set; }
public virtual Team Team { get; set; }
}
public class Team
{
public virtual int ID { get; set; }
public virtual string City { get; set; }
public virtual string Nickname { get; set; }
}
Assume the following mapping class for Player:
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" default-lazy="false">
<class name="Player">
<id name="ID" column="ID" type="System.Int32" unsaved-value="null">
<generator class="native"/>
</id>
<property name="Name" column="Name" not-null="true" type="System.String" length="50" insert="true" update="true"/>
<many-to-one name="Team" not-null="true" outer-join="auto" insert="true" update="true">
<column name="TeamID"/>
</many-to-one>
</class>
</hibernate-mapping>
And assume the following Player repository method:
public void Add(Player player)
{
using (ISession session = NHibernateHelper.OpenSession())
{
using (ITransaction transaction = session.BeginTransaction())
{
session.Save(player);
transaction.Commit();
}
}
}
My question:
Must I load a full-fledged Team (parent object) when I want to create a new Player?
Or can I specify a "mock" object, and only specify the foreign key?
Player player = new Player
{
Name = "Tom Brady",
Team = new TeamRepository().GetTeamByCityAndNickname("New England", "Patriots") // Is this the only way?
// or can I do this?
// Team = new Team { ID = 22 }
};
new PlayerRepository().Add(player);
And if I can't specify a "mock"
object (specifying only the
foreign key), can you please explain
why I can't?
That is, can you please give me an idea about what's going on under the hood?
Heads-up:
A fellow had nearly the same question.
Here's the answer that made the most sense.
Interestingly, when speaking about EF
4.0 during a DotNetRocks episode, Julia Lerman
acknowledged that many people want to
use the foreign key in these types of
situations.
EDIT: This answer points to the essence of my question.
Think of it like having an object that
only keeps the Id and that will load
the rest if you ever need it. If
you're just passing it arround to
create relationships (like FKs), the
id is all you'll ever need.
Well if that's the case, then why do I need to be worried about proxy objects and such? Why can't I just create a "dummy" object and specify the foreign key value if that's all that really matters?

Answer 1

you use the foreign key like so...
Team = session.Load<Team>(id);
know the difference between load and get

Answer 2

If you have access to Session at this point you can call
Team = Session.Load<Team>(id);
The premise of Load is that it will create an NHibernate proxy that can resolve itself if needed. Of course you have to be sure the id exists or you will get an EntityNotFound error if it ever tries to resolve itself.