Microsoft killing LINQ to SQL?
Interesting blog post about it. And some related information on Stackoverflow posts.
The basic gist appears to be comments made on the ado.net blog that state the Entity Framework is the only thing getting major developer time for Visual Studio 2010 and Dot Net 4.
We have known this
My response is - DUH. We have all known this. Microsoft said publicly back at the PDC 2007 that LINQ to SQL was a short term release for SQL Server because there was no other LINQ story to SQL Server. It only works with SQL Server. You cannot write a LINQ to SQL provider - there is no model for it. It was a one off technology, not extensible.
Entity Framework = Provider
The Entity Framework is the ONLY way from Microsoft to build a LINQ Provider. The Entity Framework has turned out to be quite contreversial, but I think that is partly due to the fact that LINQ to SQL has a better programmer experience today. Entity Framework will catch and surpass LINQ to SQL because it is the ORM/Mapping tool of the future from Microsoft.
I think that Microsoft has a huge investment in Entity Framework with third party vendors like us, IBM, Oracle, etc. If they want third party developers and databases to support LINQ they had to have a model to write to. Entity Framework is that answer.
I saw this coming last year when they relesed LINQ to SQL with VS 2008 and not the EF. They should never have released a closed implementation of something with so much overlap. I know they wanted a relational database story, but I think they told the wrong one. Now there are a lot of seriouly confused developers who come asking us for our LINQ to SQL provider. There isn't one because you can't write one.
VistaDB will release Entity Framework Provider
We do have an Entity Framework provider in the works. In fact we are wrapping up some presentations about it right now. So the official announcement is only a few days away.
EDIT
According to this blog LINQ to SQL was supposed to have a provider model:
LINQ to SQL was actually designed to be host to more types of back-ends than just SQL server. It had a provider model targeted for RTM, but was disabled before the release. Don’t ask me why. Be satisfied to know that is was not a technical reason. Internally, it still behaves that way. The trick is to find out how to swap in a new one when everything from the language to the runtime wants to keep you from doing it.
But it never happened due to the perceived competition to the Entity Framework was the underlying message. Either way, doesn't matter. The only official way to do it according to MS is through Entity Framework.
Similar Posts
- Visual Studio 2010 VPC Preview
- Looking ahead to 2008, and back at 2007
- Set any 2008 Resolutions or goals?
Comments
Sean on on 10.31.2008 at 10:21 AM
Just FYI, you have a minor typo (misspelled release):
VistaDB will relesae Entity Framework Provider
Jason Short on on 10.31.2008 at 10:22 AM
Thanks! Fixed.
Sidar Ok on on 10.31.2008 at 12:46 PM
Official way of accessing data has been DataSets for decades.
That doesn't mean that it is the right way.
On the other hand, that paragraph about L2S, is completely wrong. First, L2S is not a one off technology, it hasn't come into the game to be replaced, and it has a longer history than EF if you read Matt Warren's posts. Secondly, It has a provider model, but it is disabled for political reasons. If you look at with reflector, you will see the provider is there and private. Third, L2S is quite extensible - There are tons of people, including me coming up with tons of blog posts on how to extend it.
L2S is the only product that can compete with NH, not EF. EF is over complicated for simple actions that you can do very very easily with NH and L2S. For only Linq support, which is not ready yet in NH, one should be either insane or a fanboy to choose EF over NH.
Lastly
"The Entity Framework is the ONLY way from Microsoft to build a LINQ Provider"
Is another not true sentence since Linq is an interface, not a way to be provided. You can write Linq to Amazon, Linq to X and you don't need a way from Microsoft for that.
Thanks for the thoughts anyway.
Jason Short on on 10.31.2008 at 3:26 PM
Linq to Amazon is NOT a provider. It is its own interface. You cannot write a LINQ to SQL Amazon. LINQ to SQL is actually only LINQ to SQL Server/CE.
If you call Microsoft today and ask them what providers can you write as a third party database that plugs into Visual Studio. You only have a few options. DDEX (ADO.NET), Proprietary interface, Entity Framework.
You cannot write a LINQ to SQL provider, there isn't one. I don't care how often people want to see "there is one but it is not public" - if it is not public then it does not exist. You cannot build to it and ship a third party product on it.
Can you write a custom LINQ provider? Yes. LINQ to Objects, LINQ to Datasets, etc. But you cannot write a LINQ to SQL provider, no such thing.
You said you have to be insane or a fanboy to use EF over LINQ to SQL. I will present a third choice - hemmed in by Microsoft. We are a third party database. We have no choice other than to implement an Entity Framework provider. You can't build a LINQ to SQL provider...
I agree that NH and LINQ to SQL both have better models for now. But the EF is much more than an ORM. Just not today. The point of this post is that the future providers for Microsoft will be Entity Framework based. You will see an Oracle Entity Framework provider and not a LINQ to SQL Oracle. We as third parties have to live by MS's choices of what they choose to expose to us.
Jason Short on on 10.31.2008 at 5:26 PM
And the posts over on Stackoverflow are quite funny around this topic. IQueryable Provider is NOT a LINQ to SQL provider. Anyone can write an IQueryable Provider. But you get no designer support, or model generation from it. That is for code only. The Entity Framework remains the only provider model that ties into Visual Studio and gives you full design time support for the GUI, model generation, etc. If someone knows of another one please let us know. All of our conversations with Microsoft employees all point to EF as the only model that is supported with a provider model.
Michael on on 11.01.2008 at 3:41 PM
damieng.com/.../linq-to-sql-nex
Interesting comment: "The internal provider model won't go public. Writing your own provider is a complex task - the SQL Provider in LINQ to SQL represents around 70% of the runtime source. If you're replacing 70% of the product and the mapping tools you may as well write your own LINQ provider an skip LINQ to SQL."