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).

It seems to me that Danny Simmons must be working on v2 of Entity Framework.

The posts he has written in the past week are examples of things that would probably have been in V1 had they had the time and resources. Now they are winding down v1, building up the team and thinking about v2.

Danny has written three blogs posts filled with really handy extension methods for entity framework (and LINQ to Objects) [here’s the third which contains pointers to the first two] and now he is building a state bag for dealing with getting  entities across boundaries SOA style (i.e. web services and dealing with the limitations of XML serialization – something many of us have been writing about for a while).

I”m really pleased to see this coming out of Microsoft (although what happened to whitepapers? ;-)). I have come up with my own methods (some with help from Danny and some on my own) but it’s always a little unnerving when you are just making your best guess at what they might have planned for.

Months ago I started a thread on the MSDN forum about this issue and it ended up being a 3 or 4 page thread because every time someone on the team said “well, just do this” I said “no – that doesn’t really solve the problem”. I was pretty relentless (thanks to all of the work I have done with web services and ws-* in the past) and finally Danny ended the thread with “okay, obviously there’s more we need to look at here.”

Since then I have struggled to come up with disconnected solutions that deal with binary and xml serialization and presented them at a few conferences. This was with Beta2 and there are some new goodies in Beta3 that will ease the pain somewhat but it’s still pretty complex.

For the last week or so, Danny has been writing a series of blogs where he’s using his indepth understanding of entities, object services, statemanagment, etc. to build a “state bag” for transferring the whole kit ‘n caboodle across processes. It’s impressive as hell but there was something bugging me that I was dwelling on, and Roger Jenning’s pointed it out on his blog as well.The answer to “why is ObjectContext not serializable?” is that it’s big and it would not be scalable. And no, I’m not suggesting that Danny forgot this. 🙂 Which is why I’m biding my time to see how it comes out.

I’m assuming that Danny’s state bag is a proof of concept for a v2 solution (though he has been clear that because of some obvious issues with interop, it just may not go in.) And as he suggested in today’s post, readers (like me) are probably “chomping at the bit” to see how he does the object context part so that we can see how streamlined it is.

Most people have no clue how deep Entity Framework goes and what the ADO.NET team is setting up for us to be able to do with it down the road. It’s probably clear by now that I’m really excited about Entity Framework and I’m struggling to keep up with all of the great ideas that people are trying out as evidenced in the forums.

So while we’re all looking forward to the release of Entity Framework, I’m already starting to get excited about what’s going to come in V2.