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. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
