>Newbie to .NET data apps here, coming from a Visual Foxpro background.
>
>I'm planning on an ASP.NET and/or Silverlight UI, and maybe some WPF client stuff too on our LAN too, so I want to craft a data access layer that can support all these front ends.
>
>My data will be in SQL server. I have already made a test run of pushing the data from Foxpro to SQL Server 2005. It went well. That gave me a SQL server data store to play with.
>
>Now, here are the data tools I played with so far, trying to get familiar with .NET data access:
>
>1. I've played with Linq-To-Sql, and made a test form using the typed objects and collections from L2S, and then populating some WPF listviews and other UI controls. That was cool. Linq is cool! WPF is cool. See screenshot of form here: http://twitpic.com/26w26/full
>
>and
>
>2. I've played with what I guess you'd call classic ADO.Net DataSets. Man, DataSets seem like a lot of work... A SQLConncetion A SQLCommand A DataSet A TableAdapter
>
>...and worst of all, I had to type SQL code within quotes, with absolutely no help from the IDE to to keep me from making typing errors, or writing just plain wrong SQL code, and I had to know the columns names from my data table every time. Lots of room for errors! And query parameters, yuck.
>
>So, let me ask.... does the .NET developer community really work with SQLCmds, DataSets, and DataTables to read and write data? Is that how it works?
>
>I know all about the O/RM battles out there, and EF too.
>
>It sure looks like you can hook up any of the UI controls from ASP.NET/Silverlight/WPF/and WinForms to either Object collections (via OR/M) or DataSets/DataTables, right? Is it always a choice between one of those two?
>
>So, it's decision time for me, but, I don't know that to choose. They all seem to work, but that darn DataSet thing just seems scary to me, but, somehow, it also seems to be commonly used.

Matt,
Probably it is a little bit late. I would suggest to go with Linq. L2S and L2E. L2E - Linq to Entity Framework is where the MS technologies are going and there is tremendous support in VS2010 for Linq - > WPF and SL. Linq resembles the bright side of functional languages and it is much better than using the dataset IMHO (behind the scenes it is still used if need be but let framework does it, you simply code in object thinking). Learning Linq you are also partially equipping yourself with other new cool stuff emerging.

Update: Reading thread, I see that there is a misconception that you need to hardcode or must save the connection string. It is not true. You can create a DataContext with:
-connection string
-IDbConnection
or ObjectContext with:
-Connection string
-EntityConnection

That practically means you can design and develop against a test database and easily switch to your heart's liking production db.

Second misconception is about Stored Procedures. They are supported both in L2S and L2E. You can simply drag drop in L2S and map to an existing table by dropping on it. In L2E, it is different and needs some work (at least today), separated into action queries and select queries.

Cetin