The concept of this idea, is that NHibernate don`t have to work in the same way if is managing and Entity (associated to a Session) or if is managing a detached object (it´s only a POCO). This is the funcionality that provides EF and is more flexible and allows you to pass this items to another layer that don´t have to know if is working with and Entity or POCO it only receives a Book
If you manage correctly the transactions and the live of the sessions, you have to add and extra work to transform and Entity to DTO and DTO to Entity and managing internal properties and collections on this transformations. In the example thats you mention before in the first point "Are you suggesting that this ‘setting’ would make the book.Author incorrectly return null at step 1 when the book is loaded?" No, I suggest that NHibernate works in different way, if the entity is atached and the session is not closed the proxy has to load the Author, but if the session is closed or the object is detached of this session, it doesn´t thrown any exception getting the Author, only return null because it´s only a Book no a ProxyBook it has been detached and now is only a POCO I read in many sites that is better create another object to pass to another layers in place of the domain objects, but what is the advantage of this way to justify the extra work? I'm working in a dynamic language in the UI, I don't have strongly typed objects and my UI knows whats is loading in each view. Why i have to create for example 5 Book DTO different depending in the context that the UI layer is demanding, one book for show the product, another for the view of invoices.... I think that many web solutions can go in the same direction, with the increasing popularity of javascript and jQuery and this could be a good point to choose and ORM if you have to manage this extra work or it has the flexibility for work in a disconnected way.
