EDABlog

Can anyone see a use for Datasets these days  ? LINQ for SQL seems to have all the bases covered with a much easier and extensible model.

Performance

Performance varies dramatically for simpler queries and updates LINQ2SQL seems to have it , but for more complex queries datasets have an edge .  Complex reports are better in datasets but the time for reports to complete is not that relevant as they don't execute so often.

Here are some benchmarks

http://www.codeproject.com/KB/database/linqVsADO.aspx provides a simple query result and shows simple retrieval.

http://visualstudiomagazine.com/features/article.aspx?editorialsid=2372 provides a more complex query which shows lazy loading an area where ORM all have issues but with a large cache these seem to be less in practice.

SELECT DISTINCT P.*
FROM [Products] AS P
   INNER JOIN [Order Details] AS D
      ON P.ProductID = D.ProductID
   INNER JOIN Orders AS O
      ON O.OrderID = D.OrderID
   INNER JOIN Customers AS C
      ON O.CustomerID = C.CustomerID
WHERE C.Country = @Country
ORDER BY P.ProductID

Its worth noting with services and caching LINQ2SQL can gain a significant edge as queries will be simpler.

Flexibility and Maintainability

The programming model is significantly easier for LINQ2SQL. Both have their issues with  nTier systems though IMHO datasets have a significant issue with identity inserts and having to reconcile them ( much worse than LINQ where you have to re fetch/attach and re-apply the changes) .  

Though both are set based  systems the big gain LINQ has is the objects can have methods and additional fields via partial classes greatly  improving code quality ,maintainability and flexibility.

Ease of use

Ease of use is similar for simple applications but as application get more complex LINQ2SQL gets a big edge while its clumsy to add a SUM field to a datatable adding something unusual like GMT date requires clumsy code which loops through and inserts the custom rows.

Here is an example

AdventureWorksDataContext AdventureDB = new AdventureWorksDataContext(
            "Data Source=ISSY;Initial Catalog=AdventureWorks;Integrated Security=True");
//Products is the table we draged and dropped in the dbml designer
var _data = from _products in AdventureDB.Products
            select _products;
dataGridViewLinq.DataSource = _data;
//Thats it!

SqlDataAdapter adapter = new SqlDataAdapter("select * from Production.Products",
            "Data Source=ISSY;Initial Catalog=AdventureWorks;Integrated Security=True");
DataSet ds = new DataSet();
int x = adapter.Fill(ds);
dataGridViewADO.DataSource = ds.Tables[0];

Adding a query or altering it requires a new adapter  for a Dataset for LINQ2SQL  you just change the line

var _data = from _products in AdventureDB.Products
            select _products;

Integration with other systems

IMHO ease of use with other packages is probably the most important thing and both systems are comparable but LINQ2SQL works better with the newer technologies.

Longevity

Datasets and LINQ for SQL have similar development commitment from Microsoft ( the only one going forward seems the more bloated Entity Framework) however LINQ2SQL being based on POCO's will be compatible with most systems going forwards.

Overall

I can see no real reason to continue using Datasets especially due to the difficult maintanence , ( its IMHO one of the main reasons RAD apps are hard to maintain) . The long term maintenance also makes the move worthwhile  and all teams by now should have a sufficient skillset    in working with POCO objects.  If teams are working with Windows Communication Foundation they should move immediately.

Note im mainly referring to RAD style applications or services large OO type applications should consider EF(Entity Framework) , nHibernate or other auto generalting tools like LLBLGEN