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.

This is a small milestone for me.

I had to add a feature to a website for a client and thought it would be a great opportunity to use LINQ to SQL. So I built the feature with LINQ to SQL , had the sysadmin add .NET 3.5 runtime to the webserver and deployed it.

Works great!

Big grin….

My last post was about LINQ and EF Data Providers, which made me think of this.

I received an email recently asking if I knew of anyone writing an Entity Framework provider for Access.

I don’t happen to know of any.

However there’s a reason.

In the forums, there is a post from July where Danny Simmons explained the hurdles with a possible Access provider:

The OLE-DB ado.net provider has not been extended to support the entity framework, and we do not currently have plans to do so in our first release.  Further, this would be a fairly difficult effort because OLE-DB doesn’t provide enough information in general to translate CQTs (canonical query trees–the entity framework intermediate query representation) to a particular back-end query syntax.  So, while it would be possible to write an Access provider which would translate from CQTs to the particular query syntax that access uses, we don’t have an access-specific ado.net provider, and the general OLE-DB provider would not be able to do the job.

We have done some internal prototyping of how Access and the entity framework might work great together in the long-run, but those were just explorations, and we will not have direct support for Access in the first release of the entity framework.

People are always asking “when will I be able to use LINQ against databaseA or databaseB?” and “when will I be able to use Entity Framework against databaseA or databaseB?”

In my mind this is the same question, though most who are asking don’t realize it. Why?

An Entity Framework provider gets all of the benefits of the Entity Framework and also gets LINQ for free by way of LINQ to Entities.

If a database vendor wants developers to be able to perform LINQ queries against their database, it’s not a stretch to think that they might also want developers to be able to use their database within the Entity Framework.

Why write two providers (a LINQ provider AND an EF provider) when they can write just an EF provider and with it, get LINQ capabilities as well?

An added benefit is that with Entity SQL, it is possible to add provider specific functions.  So when a developer reaches a wall trying to write a LINQ query, the can just step back and use Entity SQL for those cases.

I’m definitely using LINQ to SQL where it makes sense for me. In fact, I’m waiting for a sysadmin to throw .NET 3.5 on my client’s web server so I can deploy my first production solution that uses LINQ to SQL! 🙂

But for any other db’s, I’m not waiting to see who is writing LINQ providers for their databases, but who is writing EF providers (here’s a current list, by the way).