I created an NHibernate app that uses WCF for remoting -- sending domain objects across the wire to a Windows "smart client." There's a trick you need to know to do this. I wrote about it here: http://lunaverse.wordpress.com/2007/05/09/remoting-using-wcf-and-nhibernate/
This may have changed with newer versions of WCF and NHibernate. That said, I don't recommend this approach. Aside from the well known arguments for SOA, you have the practical problem of lazy loading, as has been mentioned. If I were starting this over, I would use a DTO approach. On Feb 1, 10:57 am, Frederic <[email protected]> wrote: > John Rayner a écrit : > > > If your domain aggregates are reasonably well-defined, you can keep > > track of the size of the WCF payload. Personally, I have no big > > problem giving read-only access directly onto entities, although I > > shudder at the thought of taking update messages in this fashion (i.e. > > simply persisting a desrialized object). My project exposes entities > > from read access and uses separate command objects for insert / update > > actions. > > > OTOH exposing domain objects doesn't give you the ability to have > > multiple "views" of the same object, e.g. a small class containing > > basic person details, and a larger class containing their full > > profile. Using entities + DTOs means that you can use the same entity > > and map onto a different DTO for serialization. Exposing entities > > directly means that you need to create multiple entity classes (e.g. > > PersonSummary and Person). This can feel a little bit odd, but IMO > > it's manageable. I imagine that DDD purists would tell me that this > > is just wrong! :-) > > > Cheers, > > John > > > On Jan 30, 8:03 pm, Eric Hauser <[email protected]> wrote: > > >> The biggest pitfall to consider is how much data will be serialized > >> when you expose your entities over WCF. For instance, you can map a > >> collection that may be very large on an object and if you are not lazy > >> loading, all of that data will be serialized over the web service. > > >> The answer really is "it depends", but assuming this is an large > >> project, I always consider my web service contracts to be data > >> transfer objects. Explicitly copy the data from the entities onto the > >> contract. It is best to think of web service objects as messages and > >> not entities. There should be a decent amount of information on this > >> subject if you do some searching. > > I quite agree with you. You can take advantage using DTO. > > One of the top advantage, is that with do not have a strong correlation > between persistence and business. > Most of the developper appreciate this separation of concerns, and it > gives us more control over the database. > > And the same way, you can re-use entities, stop thinking in terms of > database. > > DTO are not that bad. > > fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
