Is Linq to SQL still a viable choice for developing applications?

Question

I'm reading up on .NET things again after a brief (and occasionally ongoing) stint with Ruby on Rails. I'm wondering if LINQ is still a choice when choosing an ORM for new applications, or if I should learn something like NHibernate instead which seems to still be going strong. I know that Linq has basically been subsumed by the Entity Framework, but when I tried EF (this was a while ago) I found it far too heavy and too "mouse-driven" (i.e. a lot of playing around with a designer). I've watched a few short screencasts on NHibernate and I do like the separation of concerns that it enforces as well as the idea that your Model can be kept clean.

Linq's syntax is pretty nice though, but it's not a true ORM and I don't want to look at learning something that's basically obsolete when I can learn something that's being used or will be used (EF and/or NHibernate, for example).

So, is Linq still something that should be considered using in an application (let's assume something of moderate complexity; not a trivial application, but not a huge undertaking; around as complex as a web-based application like 37Signal's Highrise) or is there something better that's worth looking at instead?

Answer 1

I believe StackOverflow (still) runs on LINQ to SQL so it would be kind of odd to say that it is not a viable choice. I have done a few demos with it in WPF and ASP.NET and it is straight-forward, easy to use. What you can't do with it you do with straight SQL.

Answer 2

You need to differentiate between LINQ as a programmign language concept (Language Integrated Query), and Linq-to-SQL as a SQL Server-oriented database mapping ("ORM") tool.

LINQ as such - as a technology - is definitely here to stay - no question about that.

Linq-to-SQL is a bit different, in that Microsoft will not put much resources into its further development anymore. For .NET 4.0, they are coming out with some enhancements and bug fixes, but nothing major.

So if your app is small and you don't really envision it to last 10 years or more in production, you can still pick Linq-to-SQL as a very viable and useful technology to get up and running quickly and easily - as long as you only ever need SQL Server as your database backend.

If you're in a more enterprise-oriented environment, if your app will likely last 10 or more years, or if you need heterogeneous database backends, or if you need to map between disparate physical schema in your database and your object domain model - then pick the ADO.NET Entity Framework and Linq-to-Entities. It offers quite a bit more punch than Linq-to-SQL - at the cost of a higher learning curve.

Your pick - both technologies are definitely great ways to build apps today and for the next 2, 3, 5 years - after that, all bet's are off :-)

Marc

Answer 3

Linq is not an ORM and Linq is great. You very likely want to use Linq if at all possible.

LinqToSql is an ORM, although it is very light feature wise. It gives you basic (and primarily one time) code generation of active record type data layer classes based on a SQL Server database definition. While it supports some basic ORM features, most anything else you want, you are going to have to create yourself.

EntityFramework is also an ORM. While it shares some of LinqToSql's limitations, it also does some things better and some things worse. The current V1 has many limitations, some of which will be addressed in the next version (V4) that comes out with Visual Studio 2010.

Neither LinqToSql or EntityFramework are mature, proven ORMs. Both have significant drawbacks that you are likely to run into doing most "normal" software development projects.

NHibernate offers significantly more features than either of Microsoft's ORMs and you'll find that it works in pretty much any "real world" situation. If you like the ActiveRecord pattern followed by Microsoft's ORMs, NHibernate supports that as well with Castle ActiveRecord.

All three of these ORMs support Linq.

One word of caution. It can be difficult and expensive to switch ORMs mid-project, depending on how well you separate your data layer from your other layers. You can't easily start with, for example, LinqToSql and then switch to, for example, NHibernate later when you run into one of LinqToSql's many limitations unless you are really smart about how you decouple your ORM from the rest of your implementation, which can be very difficult depending on the ORM.

Answer 4

LINQ to SQL is a convenient option for the developers that need to implement not very complex database access layer (and this is rather common situation).
Our company is continuously improving the implementation of the LINQ to SQL tecnology for Oracle, MySQL, PostgreSQL and SQLite databases.

Answer 5

I would add that L2S is one of the fastest options you have on .NET. Taking into account the quality of supported LINQ features, it can be the best choice in wide range of cases.