So it’s a way of loading a referenced object without fetching any state? In your example I would fetch the category and then set product.Category = categoryProxyThatIsntInitialized right?

Say you have order.Customer and the Customer property holds a reference to a proxy. If only association properties should be virtual as you claim then merely accessing the Customer property would trigger the lazy load. But what if i only want the Customer property’s Id value? That one is already there in the proxy and can be retrieved without having to hit the database. But when i access one of the proxy’s other properties, say order.Customer.Name it needs to hit the database.

I do however still disagree that everything needs to be virtual I think that only the association properties need to be virtual. I can’t think of a scenario where you will be able to get a proxy without going via an association. For example when you load an object you get the object itself, all of its single links are instances of proxies but you can’t get to that proxy unless you do LoadedObject.SomeAssociation so all you’d really need is LoadedObject to be a proxy which loads the associated object when that property is accessed.

In the case of a multi-association again it’s the property which must be accessed in order to obtain a reference to any item in its list. How is it possible to access the proxy any other way? I don’t think it is.

So I am still utterly convinced that you only need to actually make association properties virtual. If someone reading this could give me a step by step scenario of when not having virtual properties/methods on a class could cause problems (except for not making associations virtual) I would appreciate it

Pete

Now that I know I am not making a stupid mistake I would like to discuss it with you. Do you think you might have 5 mins spare to chat on skype (mrpmorris) or msn (mrpmorris@live.co.uk)? I’m not after support or anything because I am not currently using NH I just wanted to discuss some ideas etc.

Cheers

Pete

but for a many-to-one association, the proxy will indeed be derived from the base type for reasons i’ve already explained earlier

Maybe I am misunderstanding the problem. Let’s take this model

JobBatch 1—* JobAction

Where JobAction is abstract and has an abstract Execute method. Now let’s say that my lazy-load JobBatch object is used like this

foreach(JobAction action in job.Actions)
action.Execute();

Every instance in job.Actions is a dynamically created sub-class of JobAction isn’t it? Can you confirm this is the case? We can work from there

http://mijalko.blogspot.com/2009/03/hibernate-nhibernate-and-polymorphism.html

that has a workaround to the issue you mention, though i haven’t tried it yet

having said that (and i can’t believe this didn’t cross my mind sooner), if you feel the need to check for the actual type when all you have is a base type (whether it’s a proxy or not), you’re kinda missing out on the whole point of polymorphism, no?

the situation you are complaining about is a situation where we need to create a proxy _before_ hitting the database. If you can come up with a way that enables us to figure out which of the derived proxy type we should use without hitting the database, and without breaking anything, i would be more than happy to implement it for you. Though i can’t help but wonder why more people don’t complain about this if it really is that big of an issue.

“we can’t possibly determine the actual type _without hitting the database_”

But when you access the lazy-load object you *do* go to the database to read its content, so you do know the exact types.

right, lazy loading individual properties is not possible by default, though i do remember seeing a workaround for it once to enable it… that was far from trivial though

in case of the byte[] array, i’d either put the byte[] array in a separate table which links to the original record and map it as an association, or use a separate mapped class which uses the same table.

So the virtual is for lazy loading ALL object state then, not for identifying which parts of the state should be lazy loaded? What if your class has a large byte[] property which is only used 50% of the time? I already use an ORM which lets me mark individual elements as lazy-load, and it loads polymorphic associations properly too (http://www.capableobjects.com)

Considering its popularity I am really very surprised that NH works this way.

the only thing i’m saying is that ignoring potential access to private backing fields (and there certainly are valid reasons why people want to do that) could lead to a host of problems, which could potentially be increased when using NH because you will sometimes end up with proxies and sometimes with real instances. Simply saying “don’t do that then” doesn’t really cut it IMO.

I do think that persistence ignorance is possible, but only with a very specific custom made ORM. NHibernate doesn’t get you true persistence ignorance (otherwise we wouldn’t require virtual public members or default constructors), but i do think it gets you far closer to it than any of the alternatives (outside of rolling your own)