ASP.Net MVC, jQuery & L2S is my current technology stack.

I was wondering if MS would prefer to open source L2S implementation so that the interested community can take it forward.

I think this could be a win-win situation for all concerned…

My 2 cents

Within the first month of using Linq to Sql, our development cycles got cut down by 30%, our error rates in DAL Layer dropped to a virtual zero, and the best part was, there was almost no performance penalty.

I have played around with EF, NHibernate (used previously in 2 enterprise apps) and Linq to Sql. The only thing that I see with Linq to Sql is, that it’s tied to SQL Server. But we are a Microsoft shop and we do all our development in SQL Server, which is not a bad thing. So Linq to Sql does work out great.

I have an application that gets to the tune of 40,000+ hits per month and I am yet to see any issues with Linq to Sql. So if I know that SQL Server is being used, I would use Linq to Sql over EF. There are a bunch of things in EF that make me want to wait for a future release. NHibernate definitely takes the cake in almost everything (love their Criteria API for ad-hoc queries), but I hate the way CodeSmith templates are generated for the same. So I use it only in scenarios where I have tremendous amount of ad-hoc querying required.

So for the time being, I am sticking to Linq to Sql. Also glad to know that Linq to Sql is not going away! It is a little too tight to just throw away. Not to mention the queries generated by it are infact better than EF (or am I just dreaming this?)

I don’t know if it is right to call it an OR/M, but it gets the job done pretty good!

Thanks!
Keep up the good work!

They mixed object creation and tracking in datacontext leading enormous problem design issues.

Hope microsoft will find out a better pattern for multi tier architectures.Yes, codeproject and other articles exists, but they are workarounds.

The teams responsible for EF and L2S are now located right next to each other and there is collaboration between the teams in closing the gap for .NET 4.0.

It’s not fair to say team a did a better job than team b because they had different objectives. LINQ to SQL’s objective was to allow LINQ queries to work with a database. EF’s objective was to provide conceptual to physical data modelling that is independent of storage location/provider.

[)amien

I was always under the impression that when Entity framework was released there would be no more need for Linq2sql and we could easily port over our data layers, but the obvious lack of communication between the 2 teams has lead to 2 quite different architectures so I among many others have little faith in that even EF v2 or v3 will give us anything close to the user friendliness of Linq2sql.

The fact that Linq2sql is a superior product to Entity Framework v1 and that the ADO.NET team seems so reluctant to admit that the C# team actually did the job they were supposed to do so much better puts the ADO.NET team in a bad light. The ADO.NET team could learn some communication techniques from the asp.net mvc team and try to appear a bit more pragmatic.

However for the simple I want X,Y data from sql (my main db since after all I am a microsoft shop why would I be running anything but SQL if I am coding asp.net / ajax / silverlight. I know I could, just saying having it all MS just makes sense. L2Q just works so perfectly. Now I understand the whole point MS has of not wanting to replicate a bunch of code, and “wasting” resources on making 2 similar projects that greatly overlap, however merging the 2 together while keeping the calls to L2Q simple I dont mind if I have to make a long declaration of a class. Just allow me to make that declaration and then have my L2Q setup inside of EF.
Or let me back up out of the class tree and return to normal EF.

I know it’s much more complex then just that, but that type of merger would make both camps happy, I think. :)