.net - 使用 linq to sql 与创建自己的数据层有什么优缺点？

Question

前几天我刚开始使用 Linq to SQL，我很好奇我是否应该在接下来的项目中使用它。我知道这将为我节省大量的开发时间。我在这个主题上看到了很多类似的问题，但我还有一些更具体的问题。

继承 .dbml 文件中生成的类有什么问题吗？

生成的 SQL 命令是否高效？当我使用 SQL Server Profiler 时，我注意到当我使用 linqDataSource 绑定(bind)到 gridView 来获取所有记录的列表时，我会看到两个查询正在执行。第一个是一个

SELECT COUNT(*) and then a SELECT TOP(PageSizeOfGrid).  

为什么？

使用 ObjectDataSource 会更好吗？从存储过程中获取所有记录并缓存它们？

Entity Framework ？不太了解它，但我认为它可能对我的需求来说太重了。我的大多数数据库都是相当简单的 10 - 20 个表，可能有多对多的关系。值得研究吗？

对此的任何想法表示赞赏。谢谢!

Answer 1

Is there anything wrong with inheriting the classes generated in the .dbml file?

不，没有错。同样，您可以使生成的类继承自您自己的基类或实现其他接口(interface)而不是开箱即用的接口(interface)。

Are the generated SQL commands efficient?

是的，但一如既往，您需要密切关注它。如果您编写 linq 查询与良好的 SQL 查询一样，生成的 sql 将非常有效。 L2S 在某些场景下非常擅长优化，例如它消除了任何可以在客户端等上消除的东西。也就是说，它可以使它生成错误的 SQL，就像可以手动编写低效的原始 SQL 查询一样。 Click here for an example ...

When I used SQL Server Profiler I noticed when I would get a list of all records using a linqDataSource to bind to a gridView I would see two queries being executed. The first one was a SELECT COUNT(*) and then a SELECT TOP(PageSizeOfGrid). Why?

不知道，从未使用过 LinqDataSource。我更喜欢使用原始 linq 查询，我不喜欢自动化数据源控件/对象。希望其他人可以对此有所了解。

Would I be better off using an ObjectDataSource getting all records from a stored procedure and caching them?

和以前一样... :)

Entity Framework? Don't know much about it but I think it may be too heavy for my needs. Most of my databases are fairly simple 10 - 20 tables that may have many to many relationships. Is it worth looking into?

等到 EF 的下一个版本。它将作为 .net 4.0 的一部分发布。当前版本的 EF 还没有为黄金时段做好准备，出于某种奇怪的原因，微软决定不修补基本问题，而是将所有时间和精力投入到 4.0 上。这是否会成为 L2S 的有值(value)的竞争对手/替代品还有待观察。 (我只尝试过 beta 1，它遇到了与 EFv1 相同的问题；主要是生成的 SQL 查询不佳的问题...(ex 1ex 2ex 3 等)