What should I use instead of Linq to SQL?

Question

I've been reading about how Linq to SQL is dead (link here).

So my question is what should I use instead? I already have a project full of Linq to SQL. What's the best thing to migrate it over to?

Answer 1

I believe the entity framework is the official replacement. If your project already uses it, I would just leave it as is. From what I understand, its dead in the sense that MS will no longer be extending it. Support for it will probably continue indefinitely.

Answer 2

If you want to stick with the Microsoft stack, I think the Entity Framework in the direction they are recommending.

From the ADO.NET blog: "We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. 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."

Answer 3

Linq to SQL is not dead.... as always everyone jumped the gun on that.

http://reddevnews.com/blogs/weblog.aspx?blog=3036 ...

Answer 4

You shouldn't migrate to a different framework unless you have to.

As Linq to SQL is still supported, I wouldn't migrate unless you're actively developing functionality in that area.

However if you do decide to migrate, then the Entity framework is probably a good choice for you.

Answer 5

The is an alternative such as nHibenate http://www.hibernate.org/343.html

Answer 6

I would also strongly suggest Nhibernate with Fluent.

Fluent Nhibernate

Answer 7

Damien Guard has something to say on the future of Linq To SQL on his blog:

LINQ to SQL next steps

Where, amongst other things he states:

Firstly we are going to make sure LINQ to SQL continues to operate as it should. This doesn’t just mean making sure what we had works in .NET 4.0 but also fixing a number of issues that have arisen as people pick it up for more advanced projects and put it into production environments.

and

This isn’t to say LINQ to SQL won’t ever get new features. The communities around LINQ to SQL are a continuous source of ideas and we need to consider how they fit the minimalistic lightweight approach LINQ to SQL is already valued for. Where these suggestions fit with this strategy we will be working hard to get them into the product. Some enhancements like the T4 templates can be released independently but runtime elements need to stick to the .NET Framework schedule.

So, not entirely dead, but in statis maybe?

All that said, I've recently come against some fairly major limitiations in the "minimalistic lightweight approach" of LINQ to SQL especially when using the design surface - for example, if I have a table of blog posts, with an author, and an editor, both of which map back to a users table, LINQ to SQL makes no obvious destinction between these two mappings - so I've been looking at the Entity Framework.

Be warned though - moving to EF is not pain free - there are things that you can do in LINQ to SQL that you can't [yet] do in EF, such as:

var posts  = from p in posts where p.PublishedDate.Year == 2009 select p

EF complains that p.Published.Year isn't allowed, nor is p.Published.ToString("yyyy") or any other type of thing - one work around is to cast things ToList(), but then everything's on the client rather than back in the database.

Or say you want to return details of an Author or Editor from a blog post, you have to set up your query like this:

ObjectQuery<BlogPosts> blogPosts = BlogPostsSet.Include("Author");

Note the string literal in the Include - no compile time checking there.

Also, some methods have different names to do (similar) things: for example Single() and SingleOrDefault() will have to be replaced with First() and FirstOrDefault() - not major but annoying.

Answer 8

If you believe that Linq-to-SQL is really dead (which I doubt), you can either use

• Microsoft's Entity Framework (which is like a Linq-to-SQL on stereoids) - more powerful, more capable, but also more difficult to learn and more complex
• Subsonic (especially the v3.0 version with LINQ support), if you want something really simple, really "just works out of the box" with a fairly thin, minimal layer atop your database objects

Just my $0.02

Marc

Answer 9

Linq to SQL is best for ASP.Net MVC.

Answer 10

You should be able to migrate reasonably easily to Linq-to-LLBLGen, it's my opinion that LLBLGen is the best OR/M for .NET. Of course, opinions being what they are, you should make your own judgement :)

Answer 11

dblinq

You could keep using LINQ to SQL with the dblinq library instead

Linq to NHibernate

Sticking to an ORM and LINQ, LINQ-to-NHibernate would be a good idea as it's the most popular .NET ORM and has the largest community.

The learning curve is a bit steeper than LINQ-to-SQL though, in my view. However the mapping file format is a lot simpler than the DBML one (NHibernate uses XML too), and you can skip learning the XML mapping format by using Fluent NHibernate.

An extended example from the link above:

public class ConferenceMap : ClassMap<Conference>
{
  public ConferenceMap()
  {
    Id(x => x.Key);
    Map(x => x.Location)
      .Length(16)
      .Not.Nullable();
  }
}

...
public Conference GetConferenceByKey(string key)
{
    ISession session = getSession();
    var query = from conference in session.Linq<Conference>()
                where conference.Key == key
                select conference;
    return query.Distinct().Single();
}

Answer 12

You can NHibernate and SubSonic.