Let’s say I have a relational database with tables: OrderableCategories and Orderables. They are in a relation of one-to-many with one OrderableCategory attached to multiple Orderables. Therefore, an OrderableCategory instance in LINQ has members: ID, Name and an EntitySet<Orderable> Orderables. While sent via WCF (wsHttpBinding if it matters anyhow), the EntitySet is translated to simple Orderable[]. An Orderable Instance also contains a member called OrderableCategory which is simply an instance of this orderable’s category. While sent via WCF, I guess something like this happens: an Orderable instance fills its OrderableCategory instance with fields from this category, but its Orderable[] is also filled with other orderables in this category. These orderables have its OrderableCategory filled with this category again and so on, so that I could theoretically call (for a received orderable o): o.OrderableCategory.Orderables[0].OrderableCategory.Orderables[0]. (...) and so on. I’m only guessing that the server gets into an infinite loop and when message size exceeds the quota, it disconnects and I see an exception of service shutting down. How can I avoid this scenario and have the benefits of relations in my database? I think my suspicions are correct, because when I disabled one of the properties (made it internal in LINQ Class Designer), the data is filled “one-way” only and the Orderable has no longer its OrderableCategory member, it works. But I would like to know if this could be achieved without compromising the property.
Let’s say I have a relational database with tables: OrderableCategories and Orderables. They are
Share
This must be handled by marking entities with
DataContractattribute and setting itsIsReferenceproperty totrue. This will instructDataContractSerializerto track references instead of serialize objects as you descirbed.Linq-To-Sql designer / SqlMetal should do this for you by setting
Serialization ModetoUnidirectional.