I’ve been fiddling with the EntityBag that Danny Simmons wrote. My biggest interest was in how big the payload is.

I created a service that had two operations. The first returns “Hello World” and the second returns an EntityBag for an AdventureWorksLT SalesOrderHeader graph that includes it’s SalesOrderDetails.

Then I created a console app to call the two operations, passing in a sales order number for the second. The particular order I chose had 14 sales order details.

When digging into the message trace, here is the payload of the Hello World (it’s encrypted (symmetric) – so slightly larger than the actual 11 letters :-)) and the payload from the EntityBag when the entity is unmodified.

Next I edited the order. I modified one value in the order and one value in each detail. I deleted two details from the order.

Here’s what the EntityBag looks like after this:

Yet the payload is not very much different in size than before

It’s good to see the size of this as stake in the ground. It’s only one entity graph. Now you can see why serializing an objectcontext can be very expensive! The whole concept is still very interesting. I can see using this thing carefully, for example only sending entitybags for modified entities and not wasting the bandwidth to send a whole entitybag that just says “nothing’s changed”.

I’ll dig further (thanks for the great entertainment Danny) and tomorrow I’ll show how I built the service. There are a few WCF tricks you need to be aware of.

I haven’t fiddled with WCF in a while and it was fun digging in again and poking around in the messages.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!