如何选择ASP.NET MVC中的数据访问方法？
我用C# 2.0 WinForms编程已经有一段时间了。我开始学习ASP.NET和新的MVC框架以及C# 3.5的新特性。我在LINQ上只读了一点点，但是做了一些测试应用来尝试它。在我的WinForms应用程序中，我通常有某种数据访问层，并且自己编写了所有的SQL。当然，如果有什么东西能帮到我，我完全赞成。
我学习了www.asp.net/mvc网站上的教程，并做了实体框架示例和LINQ示例。到目前为止，他们看起来都很相似。LINQ感觉更像SQL，但实体框架感觉更像C#。
我的问题是：
- 一种方法比另一种更好吗？
- 一个相对于另一个有什么好处？
- 在使用任何一种方法时，是否有可能看到生成的SQL？
- 既然我是ASP世界的新手，web开发人员是靠在一边的吗？
回答 2
Stack Overflow用户
发布于 2009-05-05 04:21:56
2: LINQ-to-SQL具有简单(但仍然设计良好)的优点，但简单的缺点是-p。
- LINQ只适用于Server (实体框架是可插拔的；类似于DBLinq的LINQ的第三方变体涵盖了其他一些提供程序)
- 实体框架支持数据(存储)模型和对象模型之间的更多抽象- literal是文字表/列=>类/属性\字段。
- LINQ-to-SQL实际上在它所做的事情上更“完整”：。
- EF不支持UDF
- EF不支持子表达式调用(用于自定义表达式树)。
- EF不支持一些“明显”的方法，如
Single() - EF没有LINQ使用的一些TSQL优化。
基本上，EF目前更像是一个"v1“(甚至是"v0.9")产品。然而，(也是重要的)- EF很可能在.NET 4.0等版本中使有一个合适的下一个版本，因为LINQ将发生更少的变化。它是仍在维持中，但著名的是微软已选择实体框架作为旗舰产品(而不是从本质上将这两种产品共同进化为另一种)。你应该考虑一下长远的计划。
目前，我很高兴使用，但EF是长期的.因此，我使用存储库等来隐藏一些血淋淋的实现细节--一个泄漏的存储库，但务实。
3:使用LINQ，将一个TextReader分配给dataContext.Log；Console.Out工作得很好--或者我有一个写入trace.asax的。用EF，ToTraceString。
他说:我怀疑它在很大程度上是由于复杂性而分解的。那些使用带有简单模型的SQL Server的人，或者那些乐于拥有一个闪现到对象模型中的存储模型的人，目前倾向于使用LINQ(据我所见)。复杂程度较高的人和其他数据库倾向于使用NHibernate ;-p，然后使用一些EF。我想知道当EF下一次在.NET 4.0中发布时，这会有多大的变化.
Stack Overflow用户
发布于 2009-05-05 04:27:45
使用最适合你、你的团队和你的项目的方法。访问数据的方式并不重要，只要您访问它。
如果你愿意的话，你可以使用普通的旧ADO.NET。
https://stackoverflow.com/questions/823152
复制相似问题
腾讯云开发者
