I'm looking for a way to control which related entities get included when I'm serializing an entity. This has been discussed before at www.llblgen.com/tinyforum/Messages.aspx?ThreadID=13277 but I'm wondering if anything has changed since then, or if someone has come up with an approach. I am using LLBLGen 3.1.

The scenario: using WCF, I send a customer and all its orders to the client. On the client I make a change to one order and then send it back to the server. This causes the order, the customer, and all the other orders for the customer to be serialized and sent back, even though they have not changed.

It would be nice if there were a method I could override to determine whether each relation should be serialized. It's pretty easy to figure out whether related entities should get shipped back, based on whether they're new/modified or based on other business rules.

The only solution I've found is to hide all the relationships that I don't want getting traversed during serialization. For example, remove the "Orders" relationship from the Customer, so that when I serialize an Order the Customer will be serialized along with it, but at least all the other orders won't be included.

The approach discussed in the previous thread (set the FK value on the order rather than assigning the entity) only works for new child entities; it doesn't hold up if you're dealing with entities that have been fetched on the server and serialized to the client with the related entities already fetched.

ww wrote:

The approach discussed in the previous thread (set the FK value on the order rather than assigning the entity) only works for new child entities; it doesn't hold up if you're dealing with entities that have been fetched on the server and serialized to the client with the related entities already fetched.

I think that indeed should work, but you need to remove the unchanged entities before send them back. I think there is no direct way to do that but there are useful classes that may help you. See this for example, I want all dirty entities in a graph:

ObjectGraphUtils ogu = new ObjectGraphUtils();
List<IEntity2> onlyDirtyStuff = ogu.ProduceTopologyOrderedList(theCustomerToSave)
     .RemoveAll(e => !e.IsDirty);

Maybe you can send that list and perform a save on them.

The only way to make that work would be to go through every entity that's being saved and break all the links to all related entities, which gets really cumbersome.

Using ObjectGraphUtils to produce a list of dirty entities doesn't help much--you still have to break the links to the entities they reference, or those will get serialized along with the dirty entities.

I think it will be simpler to just override the serialization method and write my own serialization code.

ww wrote:

The only way to make that work would be to go through every entity that's being saved and break all the links to all related entities, which gets really cumbersome.

Yes, but can write a generic method to do so, that way you can re-utilize it.

ww wrote:

Using ObjectGraphUtils to produce a list of dirty entities doesn't help much--you still have to break the links to the entities they reference, or those will get serialized along with the dirty entities.

I think that should work, I tested here. The only thing is that you have to reassemble the graph from the list, or just pass the list to be saved, but I see why this is not practical for you.

ww wrote:

I think it will be simpler to just override the serialization method and write my own serialization code.

That indeed is another option.