I think that what he wants is to serialize partial views of the data using the entity (but it could be a DTO).
If you simply map the class to itself (or and DTO that has all the properties to solve all the queries) you cloud be loading much more data than desired. It would be cool if you colud turn off the lazy load exception just to serialize the object with the properties that has alredy loaded. On Friday, October 28, 2011 11:40:14 AM UTC-2, Ramon Smits wrote: > > > Seems like the correct behavior. If the data is incomplete and you want to > access the incomplete data when the session is not available anymore then > an exception should be thrown. > > This is an indicator that your strategy is too lazy. Make sure that enough > data is fetched before closing the session and you won't have this problem. > > Maybe a possible solution is to map with Automapper and map to the same > type. > > var mycompleteClass = Mapper.Map<MyClass, > MyClass>(Session.Get<MyClass>(1)); > > This would require that all entities used in your aggregate be registered > in Automapper. > > > This would result in a lazy loaded but complete load of your requested > entity. > > -- > Ramon > > On Fri, Oct 28, 2011 at 2:03 PM, 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, > > > > > -- > Ramon > >
