Learn LinqToSql or stick with ADO.NET?

Question

I'm debating what technology to use for an upcoming ASP.NET project.

Assumptions:

• I will be using Visual Studio 2008 SP1 (.NET Framework 3.5)
• The back-end will be a SQL Server 2005 database (or possibly 2008)
• Code will be written in C#
• I already have experience with LinqToObjects and LinqToXml
• I also have experience with ADO.NET and some libraries already built
• The project is relatively small
• The website will feature about five screens
• The database will have maybe six or seven tables
• There will be maybe 25-50 active users
• Transactions per day will probably be about 5-10 tops
• Minimal personal data will be stored
• The consequences of failure or the site getting hacked would be minimal

Options:

1. Write stored procedures and call them with ADO.NET. I can still use LinqToObjects once I'm done populating my DataSet.

2. Leverage what I know of Linq already to learn LinqToSql.

Analysis:

I already know how to do option 1, but I'd really like to use Linq exclusively. The problem with option 2 is that, according to everything I've read, LinqToSql will probably be deprecated in favor of Entity Framework.

Questions:

1. How steep is the learning curve for LinqToSql if you're already familiar with other Linq technologies?

2. Is it worth investing any time in learning LinqToSql given that it may not be further developed by Microsoft?

3. Will understanding LinqToSql help me to one day understand Entity Framework or are they too different?

4. Ultimately, which option would you recommend for my situation?

Update:

I don't want this to get lost in the comments: marc_s pointed out that LinqToSql is being further developed, at least as of .NET 4.0. Link: http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40.

I don't know if this means LinqToSql has a future after all, but it does make learning that technology a little more appealing.

One thing I didn't ask in my original post but should have: Are the flaws in Entity Framework likely to affect this project?

Thanks for the answers so far.

Further Analysis

Here is a list of LinqToSql drawbacks, based on some of the comments below:

1. You must continually update the tables and items in the designer as you make changes to the underlying database. There is no way to "refresh" or "sync" it so that it automatically recognizes changes.
2. Version control is complicated by the fact that the designer does not generate the underlying files in a consistent order.
3. The LinqToSql designer generates different code than SqlMetal.
4. There are issues/bugs involving eager loading.

Of these, item 1 is the greatest concern to me. Even with a small project, change is inevitable. I remember once trying to use the Windows Forms designer to map to a database, and it blew up in my face so many times, I abandoned it in favor of rolling my own ADO.NET helper classes.

However, it does seem like SqlMetal might be able to handle my needs perfectly. I run a command, it regenerates everything from scratch from the database, I'm done. If I keep my database simple (just tables--no stored procedures, views, or functions), perhaps SqlMetal is all I'll need.

Answer 1

LINQ to Sql is pretty straightforward if you already know LINQ to Xml or objects (Linq "objects" are just "lists")...

Linq To Sql is not deprecated by Microsoft, they just suggest to go with EF. It won't be upgraded.

Linq To Sql could be seen almost similar to EF. With EF you could do more complicated things, but at the base level is almost the same (for your site with 7 tables it doesn't make any difference).

For your situation I suggest to go with LINQ. It's fun and more rapid than SP + ADO.NET. Using a ORM in nowadays is almost a good choice. Not using it should be the exception (to me).