Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Controlling which related entities get serialized
 

Pages: 1
LLBLGen Pro Runtime Framework
Controlling which related entities get serialized
Page:1/1 

  Print all messages in this thread  
Poster Message
ww
User



Location:

Joined on:
01-Oct-2004 22:58:25
Posted:
65 posts
# Posted on: 27-Jul-2011 22:35:38.  
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.
  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8071 posts
# Posted on: 28-Jul-2011 04:33:19.  
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:
Code:
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.


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
ww
User



Location:

Joined on:
01-Oct-2004 22:58:25
Posted:
65 posts
# Posted on: 29-Jul-2011 16:11:54.  
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.
  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8071 posts
# Posted on: 30-Jul-2011 08:36:06.  
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.


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.