Is LINQ to SQL Dead or Alive? - linq-to-sql

Just when I make friends with LINQ to SQL, it appears as though MS is pulling the rug out from under it.
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
From my little bit of research, EF is way overkill for simple work. But after this announcement is there a point in continuing to use LINQ to SQL?
Beyond the future for LINQ to SQL, doesn't this just generally send a bad signal? Given the speed with which MS is throwing bits against the wall, is it rational to use any of the new bits early? (and that's being kind, it's hardly early for LINQ to SQL!).
For my LINQ to SQL work, I think I'm headed to SubSonic!
Update: A couple of new opinions:
http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx
http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

1) They can't "kill" Linq-to-SQL as it is already part of the .net framework. What they can do is stop adding features to it. That doesn't prevent the thousands of developers out there that are already using L2S from extending it and improving it. Some core areas are tricky to touch but they're solid already and the missing designer features can easily be bolted on.
2) One of the PDC EF sessions show that they have learnt a couple of lessons from the EFv1 fiasco and they are now copy-and-pasting a lot of the goodies from L2S into EF and pretending it is new EF stuff. In other words, L2S version two has just been "relabelled" EF.
3) LINQ as such (Language Integrated Query) is the best thing since sliced ice-cream and it can be used with a lot of other things than L2S (Linq to objects, Linq to entities, Linq to XML, Linq-to-anything). So the DP group's attempt to force [the vast masses of] L2S adopters over to [the less popular and currently flawed] Entity Framework is no reason to not learn Linq.
Also see this thread (which is what I believe partly triggered Tim's blog post):
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1
Update 1: The Dec 2008 issue of Visual Studio Magazine cover story by Roger Jennings is a good read on the topic, with some L2S vs EF comparisons: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
Update 2: Anders Hejlsberg was quoted in Redmond Developer News as saying "LINQ to SQL is not dead. I can assure you, it is not dead. Nothing ever goes away. We have never done that and we never will."
http://reddevnews.com/blogs/weblog.aspx?blog=3016

There's an ambiguity to your question that needs to be resolved.
LINQ != LINQ to SQL
There are a whole bunch of LINQ technologies and providers:
Linq to SQL;
Linq to Entities;
Linq to Objects;
Linq to XML;
... and those are just the ones from Microsoft. There are non-MS providers too, including NHibernate.
The blog post you linked talks only about Linq to SQL.
The key advantage to LINQ is that you can learn and use one query syntax and reuse it across multiple technologies.
Given this, I'd suggest that any perceived lack of a future for "Linq To SQL" is irrelevant, as skills you gain in writing LINQ Queries will be transferrable to other tools in the future.

We are not killing LINQ to SQL. We are optimizing for EF, but LINQ to SQL is definitely not being killed off :)
-
Scott / Microsoft.

Not only should you learn Linq (System.Linq.Enumerable and System.Linq.Queryable), you will need to learn the programming language enhancements for your .net language.
In C# 3.0 these include:
Extension methods (static methods with the this keyword on first parameter)
Compiler inferred types (var)
Lambda syntax (which generates an anonymous method or a Expression depending on context)
Initializers
Property default implementation (a shorthand)
Read more here.
In VB 9.0 there's some inline XML magic, and many other things (many are similar to the above list for C#).
Read more here.

I honestly do not understand where in that article you read that link2sql is dead.
In the blog post you linked to it says:
We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.
For me this reads like LINQ to SQL will be developed and supported in future. I wonder why you think it is dead?

Granted, I think that the choice between LINQ to SQL, LINQ to Entities and LINQ to [insert 3rd Party ORM] here provides a perfectly healthy eco-system of data access layer methodologies that a software developer can choose from. Third party providers like NHibernate, LLBLGen and even Subsonic (not sure if they're going to offer LINQ providers) will definitely make the competition better and more interesting.
That being said, it will be totally sad for Microsoft to abandon LINQ to SQL, especially since it does have a good following -- even StackOverflow is built on it.

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.
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.
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.
EDIT - I just did a slightly more detailed write up about this on my blog
EDIT2 - IQueryable Provider - is NOT the same thing as a LINQ to SQL provider. You can write your own IQueryable Provider for anything you like. You get no designer support or model generation. There is no gui designer model that I know of for tying into LINQ to SQL model generation.

I guess I don't really see the problem here. From the article you've linked:
We are listening to customers
regarding LINQ to SQL and will
continue to evolve the product based
on feedback we receive from the
community as well.
Am I missing something? What gives the impression of LINQ to SQL being dead on arrival?

Scott Guthrie told me they would not kill LINQ to SQL:
Post at LINQDev.com

Anyone remember VB6? Whether you personally loathe it or love it, Microsoft sold millions of copies, and businesses spent millions of dollars writing millions of lines of VB6. What happened next?
Well, Microsoft do still support VB6 (kind of - not the IDE).
And Microsoft still say that they are listening to VB6 customers even now (in September 09).
But are VB6 customers happy? Not since 2002, 4 years after VB6 launched.
Why not? The upgrade paths for your code investment to the replacement technology, VB.Net, are expensive.
So just consider that lesson. To me, it seems LinqToSQL support will be rather grudging. They are obliged to support it because it is in the current .NET framework. But will it be in .NET 5, 6, 7...? Just think about how much that matters to you (for all I know, it doesn't matter to you at all).

Maybe you should not bother learning Linq to SQL, but there's still the Entities Linq that they will keep.

See also http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx and the the comments there

Its obvious that 2 ORMs is one to many in Microsoft's toolbox, but to me it seems to be the wrong framework has been chosen for all the wrong reasons. The fact that the C# team did the job that the ADO.NET team was supposed to do in lot shorter time and did the job way better is tough to swallow for the ado.net team. Not that I know the internal workings of the 2 frameworks but I think it would be a lot faster to upgrade the shortcomings linq2sql has to the entity framework.
There seem to be too much politics involved and I think this is really going to hurt the asp.net reputation, since I have no trust in that Entity framework will give us a equally user friendly experience as Linq2sql. The ado.net team could also learn some communication skills from the asp.net mvc team as the clarifications on the problem is at best vague.
It would be fun learning what Scott Gu and his MVC team stands here as most of their examples are using Linq2Sql.

It was always a bit weird that with Linq 2 Sql and Entity Framework there was large areas of overlap. I think the only reason L2S only ever made it into the .NET 3.5 release was because there was a large doubt that EF would ever see the light of day. Now that EF1 is out, all be it a very rough v1, there was no need for L2S anymore.

(no, StingyJack, LINQ to SQL does not use the entity framework)
Anyway, I wouldn't worry. Tim states that they are listening to customers regarding LINQ to SQL. Judging from the enthusiasm I've seen for L2S, the customers (that's us) will speak their minds.
And, as KristoferA points out, they can't actually 'kill' L2S, only freeze it. And L2S, once polished, doesn't really require much further development. With the L2S provider in place, any advances in LINQ should be available in L2S as well. So the choice will still be ours.

The next version of Windows Phone 7, codename Mango, includes a SQL Server Compact Edition accessible via Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/

Related

Do i need to learn DataSet?

Refer to this question i am clear that DataSet is an old Technology. Now people use Linq to SQl. I am new to databas programming and learning these concepts. My question is do i need to learn DataSet first then move to Linq to SQL or i can directly jump to the later one.
In future a problem could come where i have to use only DataSet?
LINQ to SQL does not depend on DataSets. Don't learn them.
You might even want to skip ahead to Entity Framework because L2S is abandoned (alas!) by Microsoft. EF is the declared future.
Don't ever learn a predecessor technology first if you are actually interested in the successor. Learning materials for successor technologies make sure you get to know everything that is important. If DataSets were important your learning materials would tell you so.

Linq2SQL vs EF in .net Framework 4.0

So what's the verdict on these two products now? I can't seem to find anything regarding this issue SPECIFICALLY for VS2010/.net 4.0
Back in .net 3.5 days, most people believe Linq2SQL will be dead when .net 4.0 comes around, but it seems alive and well.
On the other hand, EF 4.0 seems to have gotten significant improvement.
For me, most of my work so far are small to medium sized projects, and my company is migrating from VS08 to VS10 soonish. What should I be looking at? Or really, should I spend the time studying EF4.0 or would it be time more well spent looking at nHibernate? (But back on topic, I'm really more interested in Linq2Sql - EF.)
Lastly, I am currently using entlib / unity, which framework is more friendly for dependency/policy injection?
Thanks in advance.
Here are some reasons why Entity Framework (v4) is better:
1 - L2SQL is essentially obsolete
2 - L2SQL does not support POCO mapping, EF does.
3 - EF has more flexibility (code first, model first, database first). L2SQL has only 1.
4 - EF has support for SPROC -> POCO mapping
5 - EF has Entity-SQL, allowing you to go back to classic ADO.NET when required
6 - EF supports inheritance (TPT, TPH)
7 - EF goes hand-in-hand with Repository pattern, and deferred execution via IQueryable
8 - EF components (ObjectSet, ObjectContext) are easily mockable and allow for DI
I cannot think of any reason why new projects should use L2SQL.
Some might say "Well L2SQL is good for small projects, i can drag and drop and be done with it".
Well you can do that with EF4 as well, and you'll have more flexibility/support in the long run if you decide to modify/grow your project. So that is not an excuse.
HTH
Just to add to the previous answers and comments (all three got a +1 vote from me):
a) Performance: the L2S runtime is more lightweight than EF (due to only a single layer; EF has to deal with two model layers and the mappings between them).
EF often generates a bit more verbose TSQL than L2S but most of the time that only affects readability if you're profiling and looking at the generated queries; the SQL optimizer will end up with the same execution plan most of the time. There are however some cases when the queries can grow so large and complex that it can have a performance impact.
L2S is also slightly better at doing client-side optimization of queries; it eliminates where clause predicates that can be evaluated client-side so the database don't have to worry about them. This means less work for SQL Server's optimizer, and less risk that you'll end up with a 'bad' execution plan.
b) L2S vs L2E: L2S is still slightly better than L2E at translating LINQ queries that use normal CLR methods into TSQL, especially when it comes to DateTime and methods related to it. L2E supports more or less the same things but through its' own EntityFunctions class: http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.
Both L2S and EF are great choices in my opinion, pick the one you feel comfortable with and covers the things you need now and during the reasonable lifespan of the code you're writing. Before you know it, Microsoft will probably announce yet another data access technology. They seem to do that every 3-5 years... :) DAO, RDO, ODBC, ADO, OLEDB, ADO.NET, typed datasets, ObjectSpaces, WinFS, L2S, EF, ... etc etc. Code I wrote 15 years ago against DAO is still out there, in apps that are still on the market, and it still works despite DAO being "dead" for years.
Sometimes names are reused for completely new data access technologies, but that doesn't change the fact that whatever constitutes Microsoft's latest database access technology is a constantly moving target...
L2S isn't going anywhere. The VS team has made that clear. It won't get significant improvement, but it will still be around and work just fine.
L2S is great, and easy to use for small scale projects with fairly simple data models. The trigger for me, when to choose EF over L2S is if I have many-to-many tables, or I need to map more complex entities over more than just a single table.
I know this is probably too late for the original query, but for the sake of future people with a similar question...
To my mind, the crucial aspect is whether you're doing an entirely new project or working with a legacy DB. I'm working with a legacy DB, with some rather idiosyncratic design decisions. I'd like to use EF, but it simply failed to map over these idiosyncracies, while L2S managed perfectly well.
For example. Some of the FKs contained other values than keys to related rows - effectively doubling as an FK/flag column.
Further, the FK inheritance mapping totally failed against out DB, so I opted for a flat L2S model, to get the benefits of type-checking and name checking at query time, but ended building my own mapping layer.
All of this is a horrible pain, if its any consolation to MS, I also found NHibernate incapable of the task. In my experience, in real-world usage too many DBs have these kind of issues, hence my recommendation that EF is not really suitable for brown-field develop ment.
For new projects, you have the luxury of evolving your DB design to match the assumptions of the framework. I can't do that as existing applications rely on the data design. We're hoping to improve the design incrementally, but attempting to correct all the problems up front would result in an infeasibly large migration event (for our resources).
Note: In the UK (at least), brown-field development is building houses on land that has previously been developed. Green-field development is building on our dwindling resources of countryside. I've reused the terms here.
We've just moved from VS 2008 to VS 2010 and from L2S to EF.
Even though we are using EF in a very similar fashion to L2S, it comforts me knowing that I have flexibility to do more advanced ORM should the need arise.
That said - for a small project - I would probably still use L2S. Medium to large projects I would use EF.
Also - EF seemed like a big learning curve, because the EF documentation prompted us to start investigating some design patterns like Unit Of Work, Repository, Dependency Injection. However I realised that these patterns applied to L2S as well as EF.
In terms of Nhibernate - my research (ie. browsing SO) indicates that the latest version of EF4.0 is sufficiently advanced (POCO support etc.) to be considered a competitive product.
If third-party products are appropriate for you, try using LinqConnect. This product allows you to use Linq to SQL (with some modifications) with different DBMS (Oracle, MySQL, PostgreSQL, etc.).
LinqConnect offers you the following features unavailable in L2S earlier:
Model-First approach
TPT and TPH support
POCO support
Automatic synchronization of model and database without data losses.
As for performance, the latest comparative test on OrmBattle our provider is among leaders.
Also, all EF functions are supported in our DBMS-specific providers as well.

How established are ORMs (object relational mapping) in the world of databases

I'm not a database admin or architect, so I have to ask those who do it 24/7. How established is the concept of an ORM (object relational mapping) in the world of database administration and architecture? Is it still happening, widely approved but still in its early stages, or is generally disapproved? I'm learning this area and would like to get a feel for whether it's going to be knowledge appreciated by the wider segment of this field.
A lot of places are using them, that doesn't mean they are using them well or that they are a good idea for the long term health of the database. Doesn't mean they aren't either, usually it just means the people choosing them don't think about how this affects database design, maintenance and performance over time.
ORMs are widely used. Django (python web application framework) uses SQLAlchemy. Hibernate is popular for Java programs. ORMs make SQL application development faster, reduce the amount of boilerplate code that you must write, and hide which database you are using from the rest of the application. Performance may suffer using an ORM, so be prepared to customize things as needed.
Widely used and definitely the present and near future. Database access through a handcoded layer of SQL generation was always fraught with drudgery and typos, and was unwieldy at best. ORMs let you use a persistence store in a programming way.
I thought this blog argued for it well: http://jonkruger.com/blog/category/fluent-nhibernate/ and SO posts like this (nHibernate versus LLBLGen Pro) show just how many people are using them.
I can tell you from my experience. We are a $2.5B solar manufacturing company and we are basing our next generation of products on ORM technology. We're using Linq-To-SQL, quite successfully. We are very happy with it.
The concept has been around for at least 20 years.
If you take a look at any decent web framework, whether it's Java, Ruby, PHP, C# or Python, they all incorporate ORMs. Generally, it's perceived as being a more professional choice unless you have specific needs for high performance or custom SQL.

Dump Linq-To-Sql now that Entity Framework 4.0 has been released?

The relative simplicity of Linq-To-Sql as well as all the criticism leveled at version 1 of Entity Framework (especially, the vote of no confidence) convinced me to go with Linq-To-Sql "for the time being". Now that EF 4.0 is out, I wonder if it's time to start migrating over to it.
Questions:
What are the pros and cons of EF 4.0 relative to Linq-To-Sql?
Is EF 4.0 finally ready for prime time?
Is now the time to switch over?
Well, an endless debate :-)
Yes, I firmly believe EF4 is definitely ready for prime time - Microsoft has done an outstanding job of addressing just about all the annoyances and issues with the 1.0 release of EF.
It's ready for prime time - if you need all its features.
Linq-to-SQL is a pretty straightforward, no-frills, no-nonsense OR mapper - it maps one database table to one CLR object - and that's about it. Very basic, very direct - but a rather thin layer on top of SQL Server.
EF4 on the other hand is much more
a conceptual data model in your object space
a storage data model on your database layer
a mapping layer between the two
database-independent
So if you really need support for multiple databases (and not just SQL Server), or if you really need to be able to morph the database structure into a totally different object model - EF4 is a great place to start.
If you have a simple and straightforward little to medium-size app that only needs to be able to easily and quickly map tables 1:1 to objects, then I don't think EF4 comes even close in terms of simplicity and performance to Linq-to-SQL.
EF4 is great - and if you need its power - go with it!
But if your requirements are a lot less, it might just be overkill - continue to use Linq-to-SQL (I will) and be happy with it. I don't see any good reason to dump Linq-to-SQL - it's still totally available in .NET 4, has been blessed with some bug fixes and improvements even, and it will be around for at least another couple of years.
#marc_s, #DanM:
Please do not consider this post as an advertisement :) We just want to know the opinion of advanced users of Linq to Sql.
We have implemented the following improvements in our LinqConnect (Linq to Sql Server, Oracle, MySql, PostgreSql, SQLite):
- Complex Type
- Many to Many
- Batch update operations
- Recursive support in DataLoad options
- Query level preload (like Include in EF)
- TPT support (in LinqConnect 2.0)
We also plan to add support for second level cache.
Are these improvements valuable for you?

Converting a LinqToSql DAL to EntityFramework

I've got an app that is just over 1yr old but it still evolving and will likely revolve more and more around a growing database schema in the near to mid term. The app was written using LinqToSql which has met our needs fairly well. We have run into a few pain points but have worked around them. I would currently consider this app to have fairly minimal database demands.
Now that the EntityFramework appears to be the ORM Microsoft is pushing people towards I'm wondering if it isn't inevitable that we will want to migrate in that direction.
I have heard a lot of good and bad about EntityFramework. So I am wondering if I would be better of taking the plunge now or waiting for v2.0 when VS10 arrives? Any thoughts? Will I lose any functionality if I do it now?
If I were to decide to migrate, can anyone point me at some resources on what is involved?
Thanks!
Re wait or change now? Personally, I'd wait (see Do you think it’s advantageous to switch to Entity Framework?) for VS2010 (as a minimum) - and until the beta comes out I can't check whether the things I use in L2S that EF lacks are implemented yet.
The resources etc question may be a dup of How to move from Linq 2 SQL to Linq 2 Entities??