The reason is that NHibernate will (unless instructed otherwise - see below)
NOT give you an object of the class you declared to persist, but to an internally derived class called a "proxy". The proxy is created WITHOUT accessing the database, hence all its fields - except the PK - are "totally empty" (they have the values as set by the default constructor).
Only when you call a method (any method!) on the proxy will NHibernate jump in and fill the data from database. This is done by overriding each and every method (and property) in the proxy with about the following code:
... override YourMethod(params) {
NHibernate.FillFromDatabase(this); // uses PK to do the SELECT
[return] base.YourMethod(params);
}
Therefore, everything has to be virtual!
If this is not what you can accept (one reason may be that you have generic methods - unfortunately the Dynamic Proxy library version 1.x used internally cannot create a proxy with generic methods!), then there are two options:
(a) declare that the persistent class must not have a proxy class (see doc for this). The consequence is that :1-associations to this class will always load the object eagerly, i.e. do the SELECT immediately.
(b) you can also declare "interface proxies" - this is very useful if you have the habit of declaring an interface for your business objects anyway; in that case, the proxy will be a standard delegating proxy (see you favorite Design Patterns book!), and hence no virtual methods are necessary. However, there are some tricky issues with the "is" operator in this case - if you are interested in this, I'll write another posting ...
Regards
Harald
Last edited by harald_m_mueller on Tue Jul 17, 2007 4:23 am, edited 1 time in total.
|