Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Best practice in Adapter when serializing dirty entities
 

Pages: 1
LLBLGen Pro Runtime Framework
Best practice in Adapter when serializing dirty entities
Page:1/1 

  Print all messages in this thread  
Poster Message
saggett
User



Location:
Manchester, UK
Joined on:
12-Nov-2007 15:44:46
Posted:
50 posts
# Posted on: 07-May-2008 15:29:02.  
This is a question about best practice for performance with Adapter when serializing dirty object graphs that's best illustrated by the usual Customer ... Order ... OrderDetail stuff.


Say I'm creating a new Order, with a few Order Details, like so:

Code:
var cust = FetchCustomer();
var order = new OrderEntity();
order.Customer = cust;
order.DateCreated = DateTime.Now;
order.OrderDetails.Add(CreateOrderDetail(...));
order.OrderDetails.Add(CreateOrderDetail(...));
order.OrderDetails.Add(CreateOrderDetail(...));


You get the idea.

I then want to save my new order via my WebService.SaveOrder(OrderEntity order) method. But when this is serialized into xml it's not just the Order and Order Details entities which are serialized, but the entire Customer entity as well. Now it seems to me that the only necessary bit of data to save the new order is the OrderEntity.CustomerId property, all the Customer data is unchanged and so it's pointless to serialize this also. Because even if we need the Customer entity in the SaveOrder(order) implementation Service-side, in most setups (where the client must communicate over the internet with the app server, but the db server is on the same LAN as the app server) it's more efficient to simply fetch it from the db than to require the client to serialize it back to the web service.

So my question is, is there a way to strip off unnecessary, clean data when serializing dirty entities back to the service? I'm aware that when creating order one could simply do order.CustomerId = customer.Id instead of order.Customer = customer, but that imposes restrictions on UI Developers that don't always get obeyed and it restricts possibilities data binding wise.
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14569 posts
# Posted on: 07-May-2008 18:06:50.  
Personaly I don't think there is a better way other than setting the FK directly.

  Top
saggett
User



Location:
Manchester, UK
Joined on:
12-Nov-2007 15:44:46
Posted:
50 posts
# Posted on: 08-May-2008 12:06:48.  
Should I post this as a feature request? Or is there some code I could write to strip off any given child entity without affecting the foreign key id on the parent entity? Obviously order.Customer = null won't work because order.CustomerId will then equal 0. order._Customer would work I think but that's a private field.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37804 posts
# Posted on: 08-May-2008 12:53:04.  
It's not possible to strip it off that easily. As there's an easy workaround: setting the FK in order, it's not likely we'll add this soon.

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


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

Version: 2.1.12172008 Final.