Thanks for the response guys. I want to lazily load the association.
My use case is as follows: I am trying to integrate nhibernate into an
existing system with a decent sized code based. My colleagues and I
are not keen on making all properties virtual. Therefore I have used
interfaces for all the mappings and have managed to work on an
nhibernate mapping assembly to get things working with nhibernate
changing a minimal amount of our current code. Based on this people
have bought into the idea.

Then I got to the issue of lazy loading associations. In all the
mappings I have defined an specific interface has been specified as
the proxy. Due to this I would have to change any associations in our
code base to be the new proxy interface type I have defined. Others on
the team are less enthusiastic about this. There could be side effects
in serialization and other areas I am not aware of (I am relatively
new to the team). So I tried this in nhibernate 3.1:

public class FooMap : ClassMap<Foo>
{
    public FooMap()
    {
        ....

        References<Bar>(f => ((IFoo)f).IBar)
          .LazyLoad(Laziness.NoProxy)
          .Column("BarId");
    }
}

and the code in the actual class

        IBar IFoo.IBar { get; set; }
        public Bar Bar
        {
            get { return ((IFoo) this).IBar as Bar; }
        }

I was only toying with this yesterday in a bid to try and change as
little of the code base as possible. The idea of it is to prevent
changing any associations from the concrete type to the proxy
interface type. In 3.1 this code worked. Basically it uses explicit
interface implementation for the lazy lazy loading association. The
normal property then calls onto the explicit interface implementation
performing a cast to get the concrete type. This would allow us to
change only a very small amount of code which and as mentioned this
worked in 3.1 but the association was always eagerly loaded removing
any flexibility with loading. To be clear; this was just an idea and
if designed from the ground up we would use the proxy classes as the
associations instead of the concrete type (really don't like making
all properties virtual). However I am trying to get people bought into
the idea of integrating nhibernate and am trying to sell it on the
basis that a: it won't cause a lot of undesired side effects, b: we
can integrate it iteratively into the code base whilst initially not
changing too much existing code.

Anyway.... I have played around with the settings between 3.2 (fluent
and nhibernate code mappings) and 3.1 (fluent mappings) and seen the
following (screenshot: https://www.sugarsync.com/pf/D6222235_632_46310297)

To explain the results - The columns show the relation type I was
testing, it turns out that the relation type has an effect on the
whether the object is a proxy or the concrete type. Access to the
object also seems to plays a part. Basically the top set of results is
when the association is accessed prior to accessing a property of the
relation, for example

                var bar = foo.Bar;
                int i = foo.Bar.SomeInt;

The second set of results is when the association property is accessed
without first assigning the assocation to a variable, for example:

                int i = foo.Bar.SomeInt;
                var bar = foo.Bar;


I am unsure why there would be a difference, I would have thought that
in the second instance foo.Bar is still be accessed so an instance of
something needs to be returned from that call. I'm unsure why
assigning it to a variable first makes a difference. The difference
that is affecting me can be seen in red in spreadsheet screeny linked
above. In 3.1 specifying no proxy caused the association to be of the
concrete type (although eagerly loaded). In 3.2 it is lazily loaded
but is a proxy type if an association property is accessed before the
association itself. I have repeated this test many times to verify the
results but cannot replicate the findings of the test case in the real
domain model I am working on. What I have named bar in the test always
comes back as a proxy using 3.2 although I still messing around with
the mappings to make sure I am testing under the same conditions.

If generally this is something that shouldn't be relied upon
(expecting the concrete type as opposed to the proxy) and what I was
trying to do is considered bad practise then I will have to convince
people that we have to convert to interfaces or use virtual
properties.

The code for all the tests can be found at:

https://www.sugarsync.com/pf/D6222235_632_46136486 - 3.1 test
https://www.sugarsync.com/pf/D6222235_632_46137868 - 3.2 test

The tests (although not in nunit) include mappings, configuration, sql
lite db etc and should be good to run immediately.

Any input appreciated.

Thanks

Ian

On Sep 30, 4:31 am, Joe Brockhaus <[email protected]> wrote:
> I just saw that it worked in 3.1. Interesting. :-x
>
> I have yet to upgrade from 3.1 using fluent as well .. I'll have to
> experiment w/ this some more myself. Thx for headsup. If i find
> anything i'll letcha know.
>
> On 9/29/11, Joe Brockhaus <[email protected]> wrote:
>
>
>
>
>
>
>
>
>
> > If i understand you correctly .. You want the association/reference
> > NOT lazy, correct?
>
> > If so, in your fluent mappings .. Where you have .lazyload(..) make it
> > .Not.LazyLoad(..)
>
> > On 9/29/11, Gunnar Liljas <[email protected]> wrote:
> >> Make the assertion..
>
> >> Assert.IsInstanceOf<Bar>(foo.Bar);
>
> >> instead.
>
> >> The "no-proxy" setting does not imply that the loaded instance will
> >> not *be*a proxy. It implies that it will
> >> *not be loaded using* a proxy. That's a big difference, especially in
> >> polymorphic associations.
>
> >> That said, the behavior is still a bit strange, since the assertion fails
> >> if
> >> sub properties are accessed before it.
>
> >> Hmmm....investigating.
>
> >> /G
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "nhusers" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group at
> >>http://groups.google.com/group/nhusers?hl=en.
>
> > --
> > Sent from my mobile device
>
> > ------
> > Joe Brockhaus
> > [email protected]
> > ------------
>
> --
> Sent from my mobile device
>
> ------
> Joe Brockhaus
> [email protected]
> ------------

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to