Comments on: Must Everything Be Virtual With NHibernate, Part II

By: Must Everything Be Virtual With NHibernate, Part III | The Inquisitive Coder – Davy Brion’s Blog

Sun, 27 Sep 2009 17:45:35 +0000

[...] Must Everything Be Virtual With NHibernate, Part II [...]

By: Andy Pook

Andy Pook — Wed, 23 Sep 2009 20:02:11 +0000

Seems a slightly contrived example to me.
I can buy that to get lazy loading the properties would require them to be virtual. But why must methods also be virtual? I can see in your example that side stepping the property and accessing the field behind it will also side step the lazy loading.

My response… Don’t do that then.

If you want lazy loaded properties then only use the properties. This is the same problem as when you have _any_ logic inside the getter/setter.

So, why does NH need access to the internals of my methods? What, exactly, does NH _do_ to the code? If I _always_ use properties and not fields, what is there extra for NH to do?

By: den Ben

den Ben — Wed, 23 Sep 2009 18:13:47 +0000

Apart from Customer/customer -> has to be Customer, as already stated in the comments. There’s still the ‘Why do AddOrderLine and RemoveOrderLine need to be virtual’?

Well, you kinda pointed out the solution in your _before_ link

They have to be virtual so the proxy generated by NHibernate can override them, adding some lazy loading mojo to it.

By: E

Wed, 23 Sep 2009 14:30:19 +0000

Field-backed properties are useful when you want to make the variable static or readonly. In this case, I agree that the auto-getter/setter makes the code more straightforward.

By: efdee

efdee — Wed, 23 Sep 2009 14:07:50 +0000

This feels like a fabricated example, why are you using a field-backed property instead of the auto property? If the expectation is that your property is lazy-loaded then it should not necessarily come as a surprise that your field is not.

That doesn’t mean it’s not something that people would make mistakes against or that I don’t agree to what you say

By: E

Wed, 23 Sep 2009 13:28:44 +0000

Customer is virtual (lazy loaded), customer is null until Customer is loaded. customer.DiscountPercentage will return a null reference exception if Customer hasn’t been loaded. This is a good example of why static methods can prevent side-effects.

By: Davy Brion

Davy Brion — Wed, 23 Sep 2009 11:00:29 +0000

yeah, they need to be virtual… but why? what can go wrong if they aren’t?

By: Chuck

Chuck — Wed, 23 Sep 2009 10:25:31 +0000

I would say that the two methods (AddOrderLine and RemoveOrderLine) need to be virtual. Not sure why, but everytime I have one of these methods and I forget to put virtual around these, I get errors during Factory configuration.

If I was to guess a reason it would be because of OrderLines is lazy loaded.

By: Davy Brion

Davy Brion — Wed, 23 Sep 2009 06:54:12 +0000

Yeah, you can also use interfaces to avoid virtual methods with NHibernate

the Date property should indeed be virtual, but that’s not the actual problem that i’m trying to show here

accessing the customer through the property instead of the field would indeed change everything

By: Noam Gal

Noam Gal — Wed, 23 Sep 2009 06:11:23 +0000

The Date property must also be virtual, in case an Order is being lazy-loaded as a reference from a Customer or Employee. At run time the Customer/Employee will have a proxy at hand, and will need to initialize it whenever an attempt to get the Date is made.

I am not sure about this, but maybe we also need to access the customer using the property (Customer) and not the field directly.

Wouldn’t working with interfaces all around (IOrder, ICustomer, IEmployee) make everything more transparent? The runtime proxy will implement the interface, instead of inheriting from the class, and the property calls will pass through it to the real object (after initialization) ? I remember using this method in Hibernate. Is it also available on NHibernate?