Are there some best practices when it comes to object graph serialization using WCF?

I am using WCF with Entity Framework v4 and using POCO entities. Our entities have a large number of related entities. One object can have many children objects of a different type which then in turn of many children of different types. For example a Car has 1 or many drive开发者_高级运维rs. Each driver has 0 or many children. Each child then has 0 or many friends. (Poor child with 0 friends). The example is a bit daft but you get the point.

If the client wanted to ask for a car it would make sense to return the car with a list of its drivers. It might or might not make sense to populate and return each driver's children. And the problem goes on and on.

Because your database almost always consists of only interconnected tables (leading to interconnected entities) how much of the object graph should we serialize?

• Is there a best practice when it comes to SOA?
• Should it only be the immediately related entities?
• Is there some sort of naming convention?
• Should we use different methods for example GetCar() and GetCarWithDrivers()?

---

I don't think there is any rule of thumb and I don't like the idea of returning data which client does not need. You service design should be driven by business functionality provided to clients. So if you expect that client will often need only Car you should define operation which will return only Car. If the client can sometimes also need Car with Drivers you should define second operation which will return Car with Drivers.

If your service works mostly as high level CRUD then it can be resonable to return at least first level of related objects but again that is only generalization based on provided functionality. Another helpful technique can be aggregates. In aggregates related entity doesn't make sense without parent entity. For example Car with Driver is not aggregate because Driver is separate entity. But Invoice and InvoiceLine is aggregate because you cannot define InvoiceLine without Invoice. In this case it can be useful to return Invoice with all InvoiceLines. Again this is not true in all situations. I worked on approval application where users were allowed to see and approve only Invoice header and InvoiceLines from their cost centre so if Invoice containted 50+ InvoiceLines but user was allowed to see only single line there was no reason to transfer them all.

Think about functionality provided by your service and needed complexity of transfered objects will be much clearer.

---

I did some Googling and found the following article which suggests only go to entities immediately related to the one that the client asked for. For everyone else: Service Orientated vs Object Orientated