If the dev knows what he's doing, I would know why he tries to access to a relation/collection that is not available. To send an entity over the wire is not a good idea (the same to send an entity to the view) but if you want send it with a fake-state there is no problem. The problem come when you want that NH returns fake-states.
I think that you can create an extension like: TEntity TransformToDto(TEntity entity) The TransformToDto can return a new instance of the entity assigning fake-states to the proxy properties. For example: - check for not loaded collection and assign empty - check for not initialized proxy and assign null - check for not initialized lazy-properties and assign null/default(T) - check for not initialized proxy and assign a "special" proxy who can query the server to upload its state - check for not loaded collection and assign "special" instance who can query the server to upload its state - check for not initialized lazy-properties and always initialize In practice you are in charge of the definition of the fake-state and you can be sure that NH never returns a fake-state. On Fri, Oct 28, 2011 at 11:29 AM, Victor Mingueza <[email protected]>wrote: > If you want to pass an Entity throw a WCF service or map with > AutoMapper like says Ramon Smits, could be a good point disable on the > session the LazyLoading or detach the object of the session or close > the session, and at this point you only have a POCO > > This poco instance don't have to throw any LazyLoadingException, is > not and Hibernate entity it's only a detached item with no proxys or > sessions. This feature can simplify the SOA programming with > NHibernate, because adding a DTO layer could be a tedious work in some > Applications. > > The best mode to resolve this, that i know is with AutoMapper, but you > have the problem that you have to create many POCO classes different > depending the context or service that is using it or AutoMapper loads > relations that you don´t wont to serialize in a determitated context. > If you know a better form, please tell me. > I resolve it modifiying the code of the AutoMapper creating prototypes > Mappers in place of the static instance, but this has the problem that > i have 5 DTO depending on the context of the service that gets the > request. > > Like says the Java Documentation "Once the org.hibernate.Session is > closed, they will be detached and free to use in any application > layer" > > NHibernate provides methods, to reattach and object to a session and > even merge with and object loaded in a new session. So, why the > objected detached, has to throw and exception related with a context > that is older, it's no more and Entity. > > I don´t say thats and attached object doesn´t must launch and > exception, but the flexibility of nhibernate could be better working > at different level depending in the state of and entity, if the > programmer knows whats are doing. > > Thanks, > > > On 28 oct, 15:27, Fabio Maulo <[email protected]> wrote: > > which should be the concept ? > > > > 1. please don't say me I'm doing something wrong > > 2. please give me an inconsistent result (the collection/instance have > > data but give me a null) > > > > On Fri, Oct 28, 2011 at 9:03 AM, Victor Mingueza > > <[email protected]>wrote: > > > > > > > > > > > > > > > > > > > > > Hi, can you resolve me a dude about this possiblity in NHibernate > > > > > You have checked the code for the BasicLazyInitializer class, there > > > are any posibility, that this class don´t throw the > > > LazyInitializationException without attach a new session? > > > > > If you have been working with EF Code First if the LazyLoading is > > > disabled, doesn`t throw any exception, only returns null. This > > > behaviour could be the expected if you want to serealize an entity > > > throw a WCF service and only serialize preloaded values. Or better at > > > the style of NHibernate; this option can be configurable? > > > > > At the documentation of java Hibernate says this > > > "Persistent objects and collections > > > Short-lived, single threaded objects containing persistent state and > > > business function. These can be ordinary JavaBeans/POJOs. They are > > > associated with exactly one org.hibernate.Session. Once the > > > org.hibernate.Session is closed, they will be detached and free to use > > > in any application layer (for example, directly as data transfer > > > objects to and from presentation). Chapter 11, Working with objects > > > discusses transient, persistent and detached object states." > > > > > I know that is better a DTO layer, but for some applications this is > > > soo expensive. > > > > > Thanks, > > > > -- > > Fabio Maulo > -- Fabio Maulo
