如何选择ASP.NET MVC中的数据访问方法？

Question

我已经在C＃2.0 WinForms中编程了一段时间了。我开始涉足ASP.NET和新的MVC框架以及C＃3.5的新功能。我只阅读了一些关于LINQ to SQL的内容，但已经做了一些测试应用程序来试用它。在我的WinForms应用程序中，我通常拥有某种数据访问层，并且自己编写了所有的SQL。当然，如果有什么可以为我做这个CRUD，我完全赞成。

我遵循www.asp.net/mvc网站上的教程，并执行了实体框架示例和LINQ to SQL示例。到目前为止，他们看起来都很相似。 LINQ感觉更像SQL，但实体框架更像C＃。

我的问题是：

1. 是一个方法比其他更好吗？
2. 一个比另一个有什么好处？
3. 是否可以看到使用这两种方法时生成的SQL？
4. 由于我是ASP新手，Web开发人员是否倾向于一方？

Answer 1

2：LINQ到SQL具有简单（但仍远工程）的优势 - 但是是简单;-p

• LINQ到SQL只适用于SQL下行服务器（实体框架是可插入的;像DBLinq这样的LINQ-to-SQL的第三方变体覆盖了一些其他提供者）
• 实体框架支持数据（存储）模型和对象模型之间的更多抽象 - LINQ-to-SQL是字面值table/column => class/property [| field]
• LINQ-to-SQL实际上更“完整”它确实做：
  • EF不支持的UDF
  • EF不支持这样子表达式调用的东西（自定义表达式树）
  • EF不支持一些“显而易见”的方法像Single()
  • EF没有一些LINQ到SQL使用

基本上EF在日的TSQL的最佳化现在更多的是“v1”（甚至“v0.9”）产品。 但是（而且很重要） - EF很可能有在.NET 4.0等适当的下一个版本，其中 - 因为LINQ到SQL将看到很少的变化。它是still being maintained，但着名的微软have chosen Entity Framework作为旗舰产品（而不是共同演进两个产品本质上彼此）。你应该考虑长期计划。

目前，I'm very happy to use LINQ-to-SQL，但EF是长期的...所以我使用存储库等隐藏一些血淋淋的实施细节 - 有点泄漏的存储库，but pragmatic。

3：使用LINQ-to-SQL，将TextReader分配给dataContext.Log; Console.Out效果很好 - 或者我有一个写入trace.asax的文件。使用EF，ToTraceString。

4：我怀疑它由于复杂性而大打折扣。使用简单模型的SQL Server的人员，或者很乐意拥有照亮对象模型的存储模型的人们，目前都倾向于使用LINQ-to-SQL（从我所看到的）。具有更多复杂性和其他数据库的人倾向于使用NHibernate;然后是一些EF。我想知道EF在.NET 4.0中的下一次发布时会发生什么变化...

Answer 2

使用最适合你，你的团队和你的项目的人。只要您访问数据，访问数据的方式并不重要。

如果需要，可以使用普通的旧ADO.NET。