.Net technologies blueprint: data access
1. ADO.Net is outdated and cumbersome - will recommend it only for tiny projects with weak developers not able to master new and more sophisticated technologies.
So the modern approach to Data Access is ORM (Object-Relational Mapping)
2. Entity Framework
- easy for beginner
- GUI builder and drag-and-drop generators in Visual Studio
- positive experience on using it with small well-structured database
- bad feedbacks on using this ORM on big tables, which were not designed from scratch: bad database layout is automatically copied into code
- limited customization
- significantly slower than LINQ or NHibernate
3. LINQ
- not easy for beginner, requires understanding of advanced C# language features
- is suitable also for non-relational data access (XML for example)
- drag and drop and intellisense supported for existing database
- other database support may be limited (mysql, etc)
4. NHibernate
- excellent support of different DB vendors, with no or little changes in code
- can be used when DB still does not exist and auto-generate database according to code
- powerful customization abilities - when existing DB schema is messy, classes still can be created in a clean way
- performance - faster than LINQ in write, slower in read
- good community, sometimes better than MS support according to feedbacks
- easier to understand than LINQ, but no built-in VS support
- very familiar for developers with Java background

Comments
Very nice manual for ORM choosing - NHibernate wins.
In additional I would suggest to separate between LINQ as abstraction for manipulation with collection data and LINQ as ORM (LINQ-TO-SQL) or LINQ-TO-XML.
LINQ itself is very similar to list manipulation functions in Prelude of Haskel(Erik Meijer, the creator of LINQ, has participated in designing Haskell98).
LINQ can be very useful to separate data querying\manipulation from data source like Data Access\ORM by LINQ providers mechanism.
Good points. Regarding LINQ as list manipulation tool: for many developers it is as hard to get as Haskell itself. But the Haskell idea of building the expression until the result is required surely will be used more and more in the future in different frameworks.