Separating an entity from its ISession

[Markus Ewald]

Hi!

I've got a web service (via WCF) that returns entities retrieved via
NHibernate to the client. To simplify integration, I've added some
scaffolding code that automatically starts a session when WCF receives a
request and closes it when the request returns.

This has the (desired) side effect of bombing out early if my web
service returns an entity that would lazy-load additional properties
upon serialization (desired because this would present a performance
issue, cause more data to be transmitted than I was expecting and in
case of circular references lead to a stack overflow or oom situation).

Is there a way to disconnect an entity from the NHibernate ISession so
that accessing a normally lazy-loaded reference property simply returns
null?
I tried ISession.Evict(), but it still throws an exception if I access a
lazy-loaded property of my entity after closing the session.

-Markus-

[Jason Meckley]

don't transfer the entity over the wire. build up a context specific DTO from the domain and transfer the DTO over the wire.

[fkne...@gmail.com]

+1

More specifically design a DataContract separate from the entity classes.

On , Jason Meckley <jasonm...@gmail.com> wrote:
> don't transfer the entity over the wire. build up a context specific DTO from the domain and transfer the DTO over the wire.
>
>
>
>
>

> --
>
> You received this message because you are subscribed to the Google Groups "nhusers" group.
>
> To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/NBiv3n9_qWcJ.
>
> To post to this group, send email to nhu...@googlegroups.com.
>
> To unsubscribe from this group, send email to nhusers+u...@googlegroups.com.
>
>
> For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
>
>
>
>

[Markus Ewald]

On Oct 25, 4:33 pm, fkneb...@gmail.com wrote:
> +1
>
> More specifically design a DataContract separate from the entity classes.
>

The only advantage I see would be that it gives me a little more
control over how the messages exchanged between web service and client
look.

On the other hand, I would have to write tons of boilerplate code to
copy properties from my entities to my DTOs, a process that invites
errors, especially if I'm extending my entities (eg. adding new
fields).

But I assume you're both giving me this advice because you know more
about web/database architecture than me. Do you have any resources I
could follow (books, articles or example projects)? Some time ago, I
had taken a look at S#arpArchitecture (http://
www.sharparchitecture.net/), but didn't consider it for this project.
Maybe that is the recommended architecture, given the name and all?

[Brandon]

http://automapper.org/
Your new best friend.

Brandon Law

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

[Gunnar Liljas]

"The only advantage I see would be that it gives me a little more
control over how the messages exchanged between web service and client
look."

And that's quite an advantage!

/G

2011/10/26 Markus Ewald <cy...@nuclex.org>

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

[Jason Meckley]

there isn't much boilerplate code given each object has a specific context.

I haven't worked with S#arpArchitecture. My only caution is not to use it unless you understand why it works the way it does. If you understand the why you can then make a well informed decision about if you should use it.

and as Gunnar stated: contextually specific DTO's are a huge advantage. yes, you end up with dozens of little POCOs but they are much easier to maintain. Changing a single domain object that affects multiple end points is much more complex than changing a single DTO that affects a single end point. You can also begin to introduce conventions into your application because each DTO is highly specific (ideally each DTO has exactly one purpose). automapper also goes a long way of reducing the repetition of mapping domain entities to DTOs.

[Tom Bushell]

On Oct 25, 9:22 am, Markus Ewald <cy...@nuclex.org> wrote:

> Is there a way to disconnect an entity from the NHibernate ISession so
> that accessing a normally lazy-loaded reference property simply returns
> null?

Perhaps you could get a similar result by using:

NHibernateUtil.IsInitialized(myProperty)

which returns false if a lazy loaded property has not been populated
with it's data.

-Tom

[Jason Meckley]

Maybe, but why introduce that complexity? by mapping the domain object to a context specific dto you know if the value is present or not because it was populated before it was sent across the wire. Not to mention the receiver shouldn't have any knowledge of NH.

[Joe Sadowski]

We've been using anonymous types to send our data across the wire by defining our wcf API endpoints as returning object instead of a concrete class. We have had to build a custom serializer to do this, but it allows us to have a lot of control over the response to the client without having to build classes specific to each response. 

-joe 

On Oct 26, 2011, at 12:24 PM, Jason Meckley <jasonm...@gmail.com> wrote:

Maybe, but why introduce that complexity? by mapping the domain object to a context specific dto you know if the value is present or not because it was populated before it was sent across the wire. Not to mention the receiver shouldn't have any knowledge of NH.

--

You received this message because you are subscribed to the Google Groups "nhusers" group.

To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/j7FYrrN522YJ.

[Jason Meckley]

ouch, I wouldn't return a dynamic to cross boundaries. The idea of having a explicit concrete type is to be explicit. using dynamic on the public API creates too much ambiguity.