1) Linq is much more broadly applicable than datasets.
You can do a linq query against a collection of plain old clr objects
for example, without a database in sight.

Suppose I have a dictionary collection of key/values and I want all
the objects where the key < 5 or the value is "blue"

var myPairs =  from p in myDictionary where (p.key < 5) || (p.value ==
"blue") select p;

is probably one of the most readable and most concise ways of
expressing that that I've ever seen.

2) linq to sql vs strongly typed datasets?
I wouldn't say linq to sql is more useful than strongly type datasets,
just different.
If you want to represent your data as objects, linq to sql makes that
path much easier.
If you prefer working with datasets then keep on trucking.

cheers,
Dave

And.... the number 1 reason to use linq (drum roll).... (extended drum
roll)... you want to be cool.  (the crowd goes wild! the heavens open, and
the angels sing!).

I think from the little linkq i have read that it indeed has a future though
it might turn out
to be a different future than the one Microsoft had in mind in the first
place. It will
change the way people program completely, i mean linq goest beyond Quering
Arrays,
XML documents or databases, programmers will start writing algorithms based
on linq and programs will take a very unexpected TURN. I dont know if this
will be good
or bad but we will see...

The only thing i felt bad is that the added so much stuff to c# in order to
be able to
add linq that it willnever be the same as before. C# comes froma family of
C-Style
languages which were created during the 60,70 and today such as C,C++,Java
and C#
with this new stuff C# has forsaken its ansertors legacy and it is becoming
something
totally different who would ahve thought about Anonimous Types or Extention
Methods
the closest to things like this was back when languages such as C++ and C
allowed programmers
to write Inline Assembly, but that is something we can do in C# with
Reflection emiting IL code.

I have a theory but I am not gonna saying just in case i am wrong about what
Linq is really all
about what where it came from...to give you a hint if you study Linq closely
it does pretty much
the same things for example a SQL Query Processor would do, it.... maybe
Microsoft
had all this stuff Written from many years ago all those OPERATORS such as
Where, Join etc..

and they EXTENDED C# with something similar..actually I was thinking i could
write and Minature
SQL Server using LINQ........................

hey it is here lets see what happens..and yes this bussines is all about HOW
cool I am or you are
and stuff so everyone out there is set to impress his fellows with his
knowledge unfourtunately
just becuase is cool does not mean is GOOD ..but....

If you want a full answer, I recommend LINQ in Action (Manning)

One of the design goals is to provide a uniform approach to querying
data, regardless of the source - query as a first class citizen,
rather than string literals, and without very different-looking code
for each backend. In addition, LINQ-to-SQL (since we are comparing to
datasets) provides composability - meaning that I can take an existing
query - such as the return value from:

var query = GetOpenFoosByCustomer(int customerNumber) {...}

And now I can further compose this:

var query2 = (from foo in query
                 where foo.Value > 200
                 order by foo.Created
                  select new {foo.Token,
foo.Value }).Skip(50).Take(10);

which is filtered, ordered, projected and paged - and when I look at
the results the query that is executed does all of this - i.e. the SQL
will have the extra WHERE and ORDER BY, the SELECT will only have the
two columns, and it will use either TOP or CTE (depending on the
server version) to do the paging.

This can have huge benefits on data throughput; I've reduced the
bandwidth by reducing the data volume before it left the database.

Now consider that this can be accessed through something like Astoria
(sorry, ADO.NET Data Services) - which is doing the same thing over a
web-service; minimising data throughput in distributed systems is a
"must"; but an Astoria query will look identical to a LINQ-to-SQL
query [caveat; Astoria doesn't currently support projections - only
homogenous sets].

Marc

The single BIGGEST reason to use LINQ over "traditional" ADO.NET style
programming is type safety.

If you use traditional ADO.NET with SqlConnection, SqlCommand and so
forth, you define your queries as strings in C# - no compile time
error checking possible, e.g. if you mistype a single character and
specify "SELECT Naame......." instead of "SELECT Name.....", you'll
only find out at runtime due to either a crash or no data being
returned.

With LINQ (to SQL), you get a type-safe, compile-time checkable
syntax, so if you happen to write

    var q = from myTable
               where .......
               select new { Naame,. ......}

you'll immediately get the compiler barfing at you, since you mistyped
a field name.

And of course, with the type-checking also comes Intellisense - you'll
never get THAT when typing up your queries in a string inside a C#
method.....

Marc