Would you use LINQ to SQL for new projects?

Question

I've been investigating what data layer to use for a new web-based project I'm designing and I'm very keen to look at incorporating LINQ to SQL. Its apparent simplicity, flexibility and designer support really appeals and the implicit tie-in to SQL Server is fine.

However, it has been announced recently that LINQ to SQL will be taking a back seat to the Entity Framework now that it's been passed to the ADO.NET team (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx). Sure, it will be supported in the future, but it's unlikely that it will see much more development work.

With this in mind, would you recommend me using this technology for my project or is it worth either selecting an alternative ORM (nHibernate?) or manually coding up a generic DAL?

The project itself is ASP.NET and SQL Server 2005/2008 based and will possibly use MVC, even though it's still in beta. It's a personal project, the database won't be overly complex and it will mainly be used as a prototype to look at .NET future tech. I would be basing future projects on what I learn from this one though, so the choices I make will affect larger solutions to come.

And yes, I realise that Microsoft will probably bring out a whole new data access technology tomorrow anyway! ;)

Answer 1

Well, it's mostly covered in answers here (some interesting points of view as well) already, but I'm going to say it again anyway..

LINQ to SQL (L2S) is very versatile, but it feels a tad too basic from my viewpoint. In most cases it does a good job at doing simple things, but as soon as you ask a little more of it, it gets expensive. This isn't at all a bad thing. I actually think LINQ to SQL actually suppliments the Entity Framework nicely.

Take Auto Paging with LinqDataSource for example. If you don't specify Order By/Group By then it's quite economical. Throw ordering or grouping into the mix and you start to get a spike in performance (becomes very chatty). You then pretty much have to write your own paging implementation (which isn't terribly hard, I'll admit).

I'll be the first to admit that L2S has the advantage over the Entity Framework in terms of the quality of the generated T-SQL (I should, since L2S is specifically built for querying SQL Server) and conceptually and symantically, much of LINQ to SQL is similar to EF, but where you hit the wall is on expanding needs and consideration for more complicated implementation requirements.

If I were to start from scratch and choose to devote personal development time, I'd pick the Entity Framework. Interestingly enough, I'm working on a project at the moment which uses L2S and it is being designed to scale nad handle heavy loads, but when we hit some of the more "creative" requirements, we are often forced to expand on SQL Metal (e.g. many-to-many relationships).

So.. in short.. I'd approach it thus:

a) learn LINQ to SQL as an intro (to Microsoft's ORM patterns and technology).. it gets you familiar with most of the fundamentals which are shared with the Entity Framework, and a taste of LINQ style querying (an acquired taste if you have a background in T-SQL)

b) once you've got a handle on LINQ to SQL, I'd recommend jumping over to the Entity Framework to learn the additional benefits (eSQL etc)

c) Implement a proof of concept project in both and compare the results.

Answer 2

Pick NHibernate. It will stay around for some time as a concept or the actual ORM. So it will be useful to learn both.

Answer 3

IMO, this whole thing was really blown out of proportion.

Microsoft didn't say that LINQ to SQL would be dead. They more indicated that it would be merged into Entity Framework.

I would focus on using Entity Framework as a solution, knowing that much of the LINQ to SQL will be rolled into it.

There really isn't that much difference right now anyway. The biggest complaint is that the Entity Framework is not light-weight. Does that really matter as long as you have good separation between your tiers?

Answer 4

L2S is, IMHO, perfectly fine the way it is and as you've said, isn't going anywhere. The corporation I work for has made it our standard for data access and we're using it for everything from little 5 user niche apps to 1000+ user enterprise apps with great results.

Answer 5

Check out SubSonic:

http://subsonicproject.com/

Answer 6

I think the goals of the EDM our much bigger than those of LINQ to SQL. If you are looking for a simple ORM then I think LINQ to SQL is the way to go. If you plan on building in classes that have an inheritance structure in relation to database tables that have a relational structure and do other advanced mappings, then EDM might be a good choice.

Answer 7

It's worth mentioning that this site is built using LINQ to SQL. Jeff talked about using it on the StackOverflow podcast.

Answer 8

L2S is an awesome technology, and I would never go back to old ADO.

But as you mentioned, it is taking a backseat to L2E. L2S is more than capable and I have have made numerous applications with it and have been incredibly pleased. But hearing that it will no longer be advanced put a knife in my side. So I went to check out L2E and it is nearly the same thing when it comes to SQL interaction, and in many ways I find it easier, not to mention more efficient with its relation handling. With such similarities, it seems logical to choose L2E.

I wrote a post on making the switch and comparing the two frameworks: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

I can almost guarantee that you will be happy with either of these frameworks, they are a godsend for development. The simplicity and error avoidance is second to none. I would personally lean to L2E as it will be developed more aggressively thatn L2S.

Answer 9

I use L2S heavily on my current web project and I believe the biggest hangup you will find is conflicting documentation regarding the best way to do n-tier database development.

First and foremost what you need to realize upfront is, DataContext objects are meant to last only as long as unit of work, period. Additionally, DataContext's are stateless. Once you come to grips with these two principals, using LINQ in an n-tier environment starts to work well.

On the other hand, you will see a number of people recommending some very very very bad ways to use Linq. Do not EVER make your DataContext static, this is a mistake I made early on and it worked wonders until it didn't work, then it was absolutely horrible with incorrect data crossing across different sessions, etc. Simply put, this is perhaps the biggest most gigantic no-no of using Linq and should be written in big bold letters in every document. Also, persisting a DataContext in a Session variable is an equally bad idea.

The only other major nasty I ran into with LINQ is when doing a disconnected update, you need to use the same DataContext across the entire call. For example:

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }        

You can't simply pass in a User created in a different datacontext and expect Update to work, unless you set DataContext.ObjectTrackingEnabled = false, which I would not recommend. Instead, within the same DataContext you should retrieve the existing object, update its values, then submit that changes. Keep all like tasks within the same DataContext.

I would recommend L2S though, once you get over a few niggling issues ( like the above ), it is a great technology and definatly a time saver. I would however recommend doing a thin wrapper around your DAL, so you can change easily. I am considering ( for economic reasons ) porting a portion of my code to using OpenAccess ORM -> MySql for a portion of my data access, and with a properly defined layer, this task should only take me a few hours.

Answer 10

I agree with Echostorm. L2S is good for your needs. And it is quite easy to work with...

Answer 11

If you design your app properly and isolate your data access layer well, you should go with L2S. From what I infer from your post, it's not a big project, so L2S should meet your requirements just fine, whereas plain old ADO.NET is just a no-no, and Entity Framework, is ... just don't use it, ok? Anyway, if you isolate your DAL well, you can swap L2S to something else in the future if the project grows. and even if L2S is not going anywhere, it's not going anywhere. MS stopped investing in it, but it's not going to become deprecated or something, so it's still a safe investment. Alternatively, you should evaluate NHibernate, which is simple and mature.