Should I read a book on specifically SQL Server, ADO, ADO.NET or ADO.NET Entities to learn to persist data for an ASP.NET MVC app?

Question

I know the basics of mySQL and database normalization.

I am getting into Microsoft programming now and plan to do a large website using ASP.NET MVC. The level of complexity of the website is probably similar to StackOverflow and other database-intensive websites. Except mine won't expect so many visitors of course :)

I hear Entities is the way of the future and ASP.NET MVC tutorials seem to use entities a lot instead of linq to SQL. Also I read Entities are likely to support other databases which would be useful for me later on.

I was thinking of learning to use Entities and wondered if the Microsoft DB stack requires that you first learn SQL, and then ADO.NET, and then Entities... or if a single book on Entities should cover my needs? What would you tell a motivated person to study, given that I don't want to read 6 months of learning material before coding. I want to get started soon but I don't want to misuse a database in a risky manner (security wise).

If Entities are overkill or too complicated, I could also study ADO.NET or whatever is a bit higher level than just inlining SQL queries in my code. I'm open to suggestions that work with MVC!

Answer 1

I'd suggest that you'd probably be best focusing on LINQ-to-???, where ??? could be Entities, nHibernate, or SQL. I don't think it would be particularly useful to go back and look at DataTables, DataReader, etc. You'll need to be aware of how things work under the hood with Connections, Transactions, etc., but any reasonable treatment of the LINQ-to-??? stuff should cover enough of this to get you started. If you run into issues where knowing the underlying implementations using lower-level constructs is required, you can always dig in then.

Answer 2

Well, learning good stuff never hurts but if you want to get started and you want to use SQL Server as your DB, go with LINQ to SQL. LINQ to Entities is more complicated than LINQ to SQL and is designed to make the database tier transparent. It's more useful when you need your application to work seamlessly on plenty of DB engines.

By the way, before you ask, "no, LINQ to SQL is not dead."