[Proxy] Class hierarchy casting issue

[Michael Powell]

Hello,

I have a use case where I'd like to cast an abstract base class to a
child class in order to verify one of the child class properties.

Consider, an albeit somewhat contrived example:

abstract class Juice { }
class AppleJuice : Juice { public virtual double Acidity { get; set; } }
class OrangeJuice : Juice { public virtual double Tanginess { get; set; } }

class Cup { public virtual Juice Juice { get; set; } }

I would like to test the Juice in the Cup in this manner:

Cup cup = ...;
if (((ApplyJuice) cup.Juice).Acidity > 1.5)
{
// Respond to acidity...
}

However, what I am finding is that the cast doesn't work "properly",
due to the proxies involved, I get InvalidCastException:

"Unable to cast object of type 'JuiceProxy' to type 'AppleJuice'"

Which I suppose is not surprising, but I wondered with the support for
class hierarchies, is there a recommended workaround? Do I need to do
some other form(s) of casting, or have some event handlers connecting
with ISession bits?

Thanks!

Regards,

Michael Powell

[Brandon Perry]

I solved this by using a core non-persistent class that implements the properties of Cup, then a persistent class that inherits from Cup that implements my Hibernate and persistent layer (created by, created on, etc).

Then I can cast the object to the non-persistent class when I need to ensure the proxies aren’t getting in the way. Unfortunately that was an early design decision and isn’t easy to implement on a larger/older DAL.

Just my 2c.

>
> Thanks!
>
> Regards,
>
> Michael Powell
>
> --
> You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibern...@googlegroups.com.
> To post to this group, send email to fluent-n...@googlegroups.com.
> Visit this group at https://groups.google.com/group/fluent-nhibernate.
> For more options, visit https://groups.google.com/d/optout.

[Michael Powell]

On Wed, Aug 10, 2016 at 11:55 AM, Michael Powell <mwpow...@gmail.com> wrote:
> Hello,
>
> I have a use case where I'd like to cast an abstract base class to a
> child class in order to verify one of the child class properties.

In my joining table mapping, in this case the reference from Cup to
Juice, I do something like this, which seems to work, but will want to
test it heavily.

References(x => x.Juice, "JuiceId")
.LazyLoad(Laziness.NoProxy)
.Not.Nullable();

And this seems to do the trick; at least there is literally no proxy
involved and I can do the casting that I want to do. I might lose some
proxiness about its usage, though, so need to test it more thoroughly.

[Oskar Berggren]

You can put something like this in relevant base class:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

Then you don't have to turn off proxying.

/Oskar

--
You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibernate+unsubscribe@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.

[mwpowellhtx]

On Wednesday, August 10, 2016 at 1:20:15 PM UTC-4, Oskar Berggren wrote:

You can put something like this in relevant base class:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

Do you understand what's going on with Proxying? You don't see it in your code, but what you end up with is something like this:

class JuiceProxy : Juice { ... }

class AppleJuiceProxy : AppleJuice { ... }

class OrangeJuiceProxy : OrangeJuice { ... }

Something like that, if memory serves, but I haven't verified the actual inheritance tree.

And since Cup wants a Juice, JuiceProxy fits the bill, but there is no reasonable way for JuiceProxy to be side-cast into the expected AppleJuice, much less AppleJuiceProxy, without losing necessary hierarchical details.

/Oskar

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibern...@googlegroups.com.
To post to this group, send email to fluent-n...@googlegroups.com.

[mwpowellhtx]

On Wednesday, August 10, 2016 at 12:00:17 PM UTC-4, Brandon Perry wrote:

> On Aug 10, 2016, at 10:55 AM, Michael Powell <mwpow...@gmail.com> wrote:
>
> Hello,
>
> I have a use case where I'd like to cast an abstract base class to a
> child class in order to verify one of the child class properties.
>
> Consider, an albeit somewhat contrived example:
>
> abstract class Juice { }
> class AppleJuice : Juice { public virtual double Acidity { get; set; } }
> class OrangeJuice : Juice { public virtual double Tanginess { get; set; } }
>
> class Cup { public virtual Juice Juice { get; set; } }
>
> I would like to test the Juice in the Cup in this manner:
>
> Cup cup = ...;
> if (((ApplyJuice) cup.Juice).Acidity > 1.5)
> {
>    // Respond to acidity...
> }
>
> However, what I am finding is that the cast doesn't work "properly",
> due to the proxies involved, I get InvalidCastException:
>
> "Unable to cast object of type 'JuiceProxy' to type 'AppleJuice'"
>
> Which I suppose is not surprising, but I wondered with the support for
> class hierarchies, is there a recommended workaround? Do I need to do
> some other form(s) of casting, or have some event handlers connecting
> with ISession bits?

I solved this by using a core non-persistent class that implements the properties of Cup, then a persistent class that inherits from Cup that implements my Hibernate and persistent layer (created by, created on, etc).

Then I can cast the object to the non-persistent class when I need to ensure the proxies aren’t getting in the way. Unfortunately that was an early design decision and isn’t easy to implement on a larger/older DAL.

I have view models, per se, but not necessary, as it turns out, at this layer, with a fairly simple workaround in the fluent mapping. Besides, that would only serve to further needlessly complicate matters. 

Just my 2c.

Appreciated. 

[Rasmus Hansen]

That's exactly Oskar's trick: You call the proxy, into the proxied object and get it to cast itself.

cup.Juice.As<AppleJuice>()

Try it. :-)

Alternative, you can return the inner, unproxied object, by adding a method like this to the base class:

public virtual object UnproxiedObject { get { return this; } }

Then it's

cup.Juice.UnproxiedObject as AppleJuice

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibernate+unsubscribe@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.

[mwpowellhtx]

On Thursday, August 11, 2016 at 7:23:35 AM UTC-4, Rasmoo wrote:

That's exactly Oskar's trick: You call the proxy, into the proxied object and get it to cast itself.

No, that's not what Oskar wrote, one the one hand; see below:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

This is not any different than what I attempted in the LINQ statement.

On the other hand, introducing an "UnproxiedObject" virtual property is too much. I want to keep the model itself as clean as possible without inverting proxy dependency inversions more than is necessary.

Appreciate the constructive input, though.

[Rasmus Hansen]

You can't cast the proxy. You can cast the proxied object. Therein lies the difference.

I try to avoid casting anyways. I'd rather use a visitor pattern as it maintains completeness.

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibernate+unsubscribe@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.

[mwpowellhtx]

On Thursday, August 11, 2016 at 7:43:27 AM UTC-4, Rasmoo wrote:

You can't cast the proxy. You can cast the proxied object. Therein lies the difference.

 

You haven't told me anything I don't already know, and/or learned about the nature of NHibernate and the proxied domain objects.

I try to avoid casting anyways. I'd rather use a visitor pattern as it maintains completeness.

 

Thank you.

[Oskar Berggren]

2016-08-11 11:47 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Wednesday, August 10, 2016 at 1:20:15 PM UTC-4, Oskar Berggren wrote:

You can put something like this in relevant base class:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

Do you understand what's going on with Proxying? You don't see it in your code, but what you end up with is something like this:

class JuiceProxy : Juice { ... }

class AppleJuiceProxy : AppleJuice { ... }

class OrangeJuiceProxy : OrangeJuice { ... }

Something like that, if memory serves, but I haven't verified the actual inheritance tree.

And since Cup wants a Juice, JuiceProxy fits the bill, but there is no reasonable way for JuiceProxy to be side-cast into the expected AppleJuice, much less AppleJuiceProxy, without losing necessary hierarchical details.

If you have

    AppleJuice : Juice

you will get

    JuiceProxy : Juice

but the important thing is that if you call a method on Juice:

    myJuice.As<AppleJuice>()

then if myJuice is a JuiceProxy, it will override the As<>() method, trigger any required initialization, AND THEN FORWARD THE CALL TO THE REAL OBJECT. And the real object will be an instance of AppleJuice. So when the body of the As() method runs, the this-pointer will be the real, derived, object, that you can cast.

/Oskar

 

To unsubscribe from this group and stop receiving emails from it, send an email to fluent-nhibernate+unsubscribe@googlegroups.com.
To post to this group, send email to fluent-nhibernate@googlegroups.com.

[mwpowellhtx]

On Thursday, August 11, 2016 at 7:59:46 AM UTC-4, Oskar Berggren wrote:

2016-08-11 11:47 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Wednesday, August 10, 2016 at 1:20:15 PM UTC-4, Oskar Berggren wrote:

You can put something like this in relevant base class:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

Do you understand what's going on with Proxying? You don't see it in your code, but what you end up with is something like this:

class JuiceProxy : Juice { ... }

class AppleJuiceProxy : AppleJuice { ... }

class OrangeJuiceProxy : OrangeJuice { ... }

Something like that, if memory serves, but I haven't verified the actual inheritance tree.

And since Cup wants a Juice, JuiceProxy fits the bill, but there is no reasonable way for JuiceProxy to be side-cast into the expected AppleJuice, much less AppleJuiceProxy, without losing necessary hierarchical details.

Laziness.NoProxy solves the problem. TBD what I'm giving up in proxies, but so far so good. 

[Oskar Berggren]

2016-08-11 12:59 GMT+01:00 Oskar Berggren <oskar.b...@gmail.com>:

2016-08-11 11:47 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Wednesday, August 10, 2016 at 1:20:15 PM UTC-4, Oskar Berggren wrote:

You can put something like this in relevant base class:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

Do you understand what's going on with Proxying? You don't see it in your code, but what you end up with is something like this:

class JuiceProxy : Juice { ... }

class AppleJuiceProxy : AppleJuice { ... }

class OrangeJuiceProxy : OrangeJuice { ... }

Something like that, if memory serves, but I haven't verified the actual inheritance tree.

And since Cup wants a Juice, JuiceProxy fits the bill, but there is no reasonable way for JuiceProxy to be side-cast into the expected AppleJuice, much less AppleJuiceProxy, without losing necessary hierarchical details.

If you have

    AppleJuice : Juice

you will get

    JuiceProxy : Juice

but the important thing is that if you call a method on Juice:

    myJuice.As<AppleJuice>()

then if myJuice is a JuiceProxy, it will override the As<>() method, trigger any required initialization, AND THEN FORWARD THE CALL TO THE REAL OBJECT. And the real object will be an instance of AppleJuice. So when the body of the As() method runs, the this-pointer will be the real, derived, object, that you can cast.

For comparison, consider this:

class Juice { public abstract string GetColor(); }

class AppleJuice { public override string GetColor() { return "brown-semi-transparent"; } }

class OrangeJuice { public override string GetColor() { return "yellow"; } }

If you now do:

    juiceProxy.GetColor();

clearly you would expect it to return the correct color as per above? And it will. Thus proving that there is a "hidden" instance of the correct type. The As() method I showed exploits this by simply delegating the casting to the object itself (the real object, not the proxy).

/Oskar

[Oskar Berggren]

2016-08-11 13:04 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 7:59:46 AM UTC-4, Oskar Berggren wrote:

2016-08-11 11:47 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Wednesday, August 10, 2016 at 1:20:15 PM UTC-4, Oskar Berggren wrote:

You can put something like this in relevant base class:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

Do you understand what's going on with Proxying? You don't see it in your code, but what you end up with is something like this:

class JuiceProxy : Juice { ... }

class AppleJuiceProxy : AppleJuice { ... }

class OrangeJuiceProxy : OrangeJuice { ... }

Something like that, if memory serves, but I haven't verified the actual inheritance tree.

And since Cup wants a Juice, JuiceProxy fits the bill, but there is no reasonable way for JuiceProxy to be side-cast into the expected AppleJuice, much less AppleJuiceProxy, without losing necessary hierarchical details.

Laziness.NoProxy solves the problem. TBD what I'm giving up in proxies, but so far so good.

What you are giving up is that NHibernate must now always load the juice from the database before it can create and return the Cup you asked for, instead of delaying it until you actually need the juice. If this is an actual problem or not of course depends entirely on your usecase.

/Oskar

[mwpowellhtx]

Thanks for that. So, it's a very real trade off re: hydration, lazy or otherwise, that could prove interesting. 

/Oskar

[Oskar Berggren]

2016-08-11 12:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 7:23:35 AM UTC-4, Rasmoo wrote:

That's exactly Oskar's trick: You call the proxy, into the proxied object and get it to cast itself.

No, that's not what Oskar wrote, one the one hand; see below:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

This is not any different than what I attempted in the LINQ statement.

It is in fact completely different. It is applying the cast to an entirely different object.

 

On the other hand, introducing an "UnproxiedObject" virtual property is too much. I want to keep the model itself as clean as possible without inverting proxy dependency inversions more than is necessary.

It is possible to provide both the As<T>() and "Unproxy()" methods as extension methods instead of putting them in each class. The difference is that the body of the method then need to explicitly check if the object is a proxy and ask NHibernate for the real object before applying the cast.

Untested, but something like this:

public static T As<T>(this object obj)
{

    if (obj is INHibernateProxy)

        obj = ((INHibernateProxy)obj).HibernateLazyInitializer.GetImplementation();

    return (T)obj;

}

You could even do:
    public interface IUnwrappable { /* empty marker interface */ }
    public static T As<T>(this IUnwrappable obj) { ... }

if you want to avoid exposing the extension method except for classes that you explicitly allow it for.

/Oskar

[mwpowellhtx]

That doesn't prove a thing. All that shows is that the proxy override the method. Because an AppleJuiceProxy is still an AppleJuice; but a JuiceProxy is not necessarily an AppleJuiceProxy. In fact, it is not, by the .NET type system.

I appreciate all the feedback. As I peel back the layers on this thing, clearly it's not that cut and dry and I will need to consider how best to approach the issue.

[mwpowellhtx]

On Thursday, August 11, 2016 at 8:22:07 AM UTC-4, Oskar Berggren wrote:

2016-08-11 12:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 7:23:35 AM UTC-4, Rasmoo wrote:

That's exactly Oskar's trick: You call the proxy, into the proxied object and get it to cast itself.

No, that's not what Oskar wrote, one the one hand; see below:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

This is not any different than what I attempted in the LINQ statement.

It is in fact completely different. It is applying the cast to an entirely different object.

How so? Watch what I did there.

cup.Juice is a type of Juice, correct?

So I want ((AppleJuice) cup.Juice). With me so far?

Adding Juice.As<TJuice>() { return (TJuice) this; } is no different than doing the cast external to the instance.

 

On the other hand, introducing an "UnproxiedObject" virtual property is too much. I want to keep the model itself as clean as possible without inverting proxy dependency inversions more than is necessary.

It is possible to provide both the As<T>() and "Unproxy()" methods as extension methods instead of putting them in each class. The difference is that the body of the method then need to explicitly check if the object is a proxy and ask NHibernate for the real object before applying the cast.

Well, I wouldn't put them in "each" class, for this contrived example, but usually that sort of thing would end up in a base class. Still, not very "Liskov", injecting DAL concerns in the domain layer. 

Untested, but something like this:

public static T As<T>(this object obj)
{

    if (obj is INHibernateProxy)

        obj = ((INHibernateProxy)obj).HibernateLazyInitializer.GetImplementation();

    return (T)obj;

}

This might be something to consider, but I haven't peeled back those layers in Fluent/NHibernate just yet. 

[Oskar Berggren]

Oh my god, it proves everything!  In the sample I meant that the juiceProxy instance is of class JuiceProxy. In this example there is no "AppleJuiceProxy" at all. Internally a proxy will contain a reference to an instance of the real object (AppleJuice or OrangeJuice) - thus making it possible for the call on the proxy to internally reach the correct implementation. (The real object instance will be generated the first time it's needed, by loading the object from the database - at this time NHibernate knows the proper derived type and is therefore able to instatiate the correct subclass.)

So as you say, you can't cast an instance of JuiceProxy to a derived type, but you can extract the real object from the proxy and then cast that. This is what the various "tricks" I've shown you do.

[mwpowellhtx]

Maybe I didn't explain it well, but that's where we started if you read my OP. JuiceProxy can't be cast to an AppleJuice. Because of the proxy/.NET type system, that kind of makes sense, but makes it interesting, at best, to support polymorphic/casting testing for AppleJuice things, depending whether Juice is/was an AppleJuice.

So as you say, you can't cast an instance of JuiceProxy to a derived type, but you can extract the real object from the proxy and then cast that. This is what the various "tricks" I've shown you do.

 

Yes, I appreciate that. I'm investigating that avenue.

[Oskar Berggren]

2016-08-11 13:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 8:22:07 AM UTC-4, Oskar Berggren wrote:

2016-08-11 12:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 7:23:35 AM UTC-4, Rasmoo wrote:

That's exactly Oskar's trick: You call the proxy, into the proxied object and get it to cast itself.

No, that's not what Oskar wrote, one the one hand; see below:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

This is not any different than what I attempted in the LINQ statement.

It is in fact completely different. It is applying the cast to an entirely different object.

How so? Watch what I did there.

cup.Juice is a type of Juice, correct?

In this line you are attempting to cast the juiceProxy, which as expected won't work:

So I want ((AppleJuice) cup.Juice). With me so far?

But here, you need to take a moment to ponder which object the "this" pointer really points to:

Adding Juice.As<TJuice>() { return (TJuice) this; } is no different than doing the cast external to the instance.

Hint: It is NOT the proxy instance.

In memory you will have

    proxyInstance [points to]-> realInstance  (realInstance present _after_ it's been required for the first time)

And the call path will be something like this:

    proxyInstance.As<ConcreteType>() [calls]-> realInstance.As<ConcreteType>() { so when code here runs, "this" is realInstance, not proxyInstance }

So as I said, the cast is being applied to a completely different object, compared to when you apply the cast "externally". And that is a very important difference, because it will actually work.

 

 

On the other hand, introducing an "UnproxiedObject" virtual property is too much. I want to keep the model itself as clean as possible without inverting proxy dependency inversions more than is necessary.

It is possible to provide both the As<T>() and "Unproxy()" methods as extension methods instead of putting them in each class. The difference is that the body of the method then need to explicitly check if the object is a proxy and ask NHibernate for the real object before applying the cast.

Well, I wouldn't put them in "each" class, for this contrived example, but usually that sort of thing would end up in a base class. Still, not very "Liskov", injecting DAL concerns in the domain layer. 

The benefit of having it in the base class is that the implementation is self-contained in the model, and doesn't depend on NHibernate. It will work regardless.

But yes, the fact that you need to use a special method instead of the normal cast syntax is a leak in the ORM abstraction. We must be pragmatic and apply the As<>() workaround, or try to use a pattern that avoids the need for the cast.

/Oskar

[mwpowellhtx]

On Thursday, August 11, 2016 at 8:47:18 AM UTC-4, Oskar Berggren wrote:

2016-08-11 13:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 8:22:07 AM UTC-4, Oskar Berggren wrote:

2016-08-11 12:33 GMT+01:00 mwpowellhtx <mwpow...@gmail.com>:

On Thursday, August 11, 2016 at 7:23:35 AM UTC-4, Rasmoo wrote:

That's exactly Oskar's trick: You call the proxy, into the proxied object and get it to cast itself.

No, that's not what Oskar wrote, one the one hand; see below:

public TCastTarget As<TCastTarget>()
{

    return (TCastTarget)this;

}

This is not any different than what I attempted in the LINQ statement.

It is in fact completely different. It is applying the cast to an entirely different object.

How so? Watch what I did there.

cup.Juice is a type of Juice, correct?

In this line you are attempting to cast the juiceProxy, which as expected won't work:

So I want ((AppleJuice) cup.Juice). With me so far?

But here, you need to take a moment to ponder which object the "this" pointer really points to:

Adding Juice.As<TJuice>() { return (TJuice) this; } is no different than doing the cast external to the instance.

Hint: It is NOT the proxy instance.

In memory you will have

    proxyInstance [points to]-> realInstance  (realInstance present _after_ it's been required for the first time)

And the call path will be something like this:

    proxyInstance.As<ConcreteType>() [calls]-> realInstance.As<ConcreteType>() { so when code here runs, "this" is realInstance, not proxyInstance }

So as I said, the cast is being applied to a completely different object, compared to when you apply the cast "externally". And that is a very important difference, because it will actually work.

I had to prove it to myself, but yes, I am starting to see that using a couple different test cases involving an array of LINQ selected instances, which are JuiceProxy at the array level, but which seem to be AppleJuice within each element. Also accessing which "this", within the implemented class, not the proxy/wrapper (more of a wrapper than an inherited class at that moment). The proxies can get one cross eyed real fast though to be sure.

 

 

On the other hand, introducing an "UnproxiedObject" virtual property is too much. I want to keep the model itself as clean as possible without inverting proxy dependency inversions more than is necessary.

It is possible to provide both the As<T>() and "Unproxy()" methods as extension methods instead of putting them in each class. The difference is that the body of the method then need to explicitly check if the object is a proxy and ask NHibernate for the real object before applying the cast.

Well, I wouldn't put them in "each" class, for this contrived example, but usually that sort of thing would end up in a base class. Still, not very "Liskov", injecting DAL concerns in the domain layer. 

The benefit of having it in the base class is that the implementation is self-contained in the model, and doesn't depend on NHibernate. It will work regardless.

But yes, the fact that you need to use a special method instead of the normal cast syntax is a leak in the ORM abstraction. We must be pragmatic and apply the As<>() workaround, or try to use a pattern that avoids the need for the cast.

Agreed. Thanks.

 

/Oskar

[Oskar Berggren]

Cool!  :)

 

/Oskar