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

Question

我已经在C#2.0 WinForms编程了一段时间了.我开始涉足ASP.NET和新的MVC框架以及C#3.5的新功能.我只阅读了一些LINQ to SQL,但已经制作了一些测试应用程序来试用它.在我的WinForms应用程序中,我通常有某种数据访问层,并自己编写了所有SQL.当然,如果有什么东西可以为我做那个CRUD,我就是为了它.

我按照www.asp.net/mvc网站上的教程进行了操作,并完成了Entity Framework示例和LINQ to SQL示例.到目前为止,它们看起来非常相似.LINQ感觉更像SQL,但实体框架更像是C#.

我的问题是:

1. 一种方法比另一种更好吗？
2. 一个人比另一个人有什么好处？
3. 是否可以看到使用任一方法时生成的SQL？
4. 由于我是ASP世界的新手,网络开发人员是否倾向于一方？

Answer 1

2:LINQ-to-SQL具有简单(但仍然精心设计)的优点 - 但简单的缺点;-p

• LINQ-to-SQL仅适用于SQL Server(实体框架是可插拔的; LINQ-to-SQL的第三方变体,如DBLinq涵盖其他一些提供商)
• 实体框架支持数据(存储)模型和对象模型之间的更多抽象 - LINQ-to-SQL是文字表/列=>类/属性[|字段]
• LINQ到SQL实际上是在东西更加"完整" 不这样做:
  • EF不支持UDF
  • EF不支持子表达式调用(用于自定义表达式树)
  • EF不支持某些"明显"的方法 Single()
  • EF没有LINQ-to-SQL使用的一些TSQL优化

目前基本上EF是一个"v1"(甚至"v0.9")产品.然而(并且很重要) - EF可能在.NET 4.0等中具有适当的下一版本,其中LINQ-to-SQL将看到更少的变化.它仍在维护中,但着名的是微软已选择实体框架作为旗舰产品(而不是将两种产品基本上共同发展到彼此).你应该考虑长期计划.

目前,我很高兴使用LINQ-to-SQL,但EF是长期的...所以我使用存储库等来隐藏一些血腥的实现细节 - 有点漏洞的存储库,但务实.

3:与LINQ到SQL,分配TextReader给dataContext.Log; Console.Out运行良好 - 或者我有一个写入trace.asax.使用EF,ToTraceString.

4:我怀疑它因复杂性而分解很多.将SQL Server与简单模型一起使用,或者很高兴拥有一个闪存到对象模型中的存储模型的人往往会使用LINQ-to-SQL(从我看到的).具有更多复杂性的人和其他数据库倾向于使用NHibernate ;-p然后使用一些EF.我想知道当下一次在.NET 4.0中发布EF时,这会有多大改变...