前几天我刚刚开始使用Linq to SQL，并且好奇我是否应该在即将到来的项目中使用它。我知道这将节省大量的开发时间。我在这个问题上看到了很多类似的问题，但我还有一些更具体的问题。
继承.dbml文件中生成的类有什么问题吗？
生成的SQL命令是否有效？当我使用SQL Server Profiler时，我注意到当我使用linqDataSource绑定到gridView获取所有记录的列表时，我会看到正在执行两个查询。第一个是
SELECT COUNT(*) and then a SELECT TOP(PageSizeOfGrid).
为什么？
使用ObjectDataSource获取存储过程中的所有记录并缓存它们会更好吗？
实体框架？不太了解它，但我认为它可能对我的需求来说太沉重了。我的大多数数据库都相当简单，10 - 20个表可能有多对多的关系。是否值得研究？
对此任何想法都表示赞赏。谢谢！
答案 0 :(得分：3)
如果能够仅针对SQL Server，我会跳到使用LINQ to SQL，因为它极大地帮助产生清晰的维护数据层。如果需要考虑性能，则可以选择性地使用直接SQL代码或存储过程来检索某些实体。
关于LINQ to Entities，我只需要在我必须使用ADO.NET数据服务的项目中使用它一次（原始LINQ to SQL生成的类不实现IUpdateable，所以通过这种技术使用时只读，并且我没有发现LINQ to SQL的任何令人信服的优势（我不是说没有这样的优势，只是因为我没有为我的特定项目找到它们，一些数据库表就像你的那样。）
答案 1 :(得分：3)
不直接回答您的问题。但是：我永远不会从头开始编写我自己的数据访问库。它非常耗时，而且对于单个应用来说这是一个非常普遍的问题。
有很多替代品可供选择，您很可能会为几乎任何类型的项目找到合适的解决方案。
一般来说，你不能说哪一个是“最佳”选择，但是编写自己的库最有可能是最差的。
答案 2 :(得分：3)
有什么不对吗？ 继承在中生成的类 .dbml文件？
不，没有错。同样，您可以使生成的类继承自己的基类，或者实现除开箱即用的接口之外的其他接口。
是否生成了SQL命令 效率？
是的，但一如既往，您需要密切关注它。如果你编写你的linq查询同样好的SQL查询，生成的SQL将非常有效。 L2S非常擅长在某些情况下进行优化，例如：它消除了客户端上可以消除的任何东西。也就是说， 可能使它生成错误的SQL，就像可以手动编写低效的原始SQL查询一样。 Click here for an example ...
当我使用SQL Server Profiler时 注意到我会得到所有的清单 记录使用linqDataSource进行绑定 到gridView我会看到两个查询 被执行。第一个是a SELECT COUNT（*）然后是SELECT TOP（PageSizeOfGrid）。为什么呢？
不知道，从未使用过LinqDataSource。我更喜欢使用原始linq查询，我不喜欢自动数据源控件/对象。希望其他人可以对这一点有所了解。
我会更好地使用 ObjectDataSource获取所有记录 从存储过程和缓存 它们？
与之前相同......：）
实体框架？不太了解 关于它，但我认为它也可能 对我的需求很重要。我的大部分时间 数据库相当简单10 - 20 可能有多对多的表格 关系。值得一看 成？
等到下一版EF。它将作为.net 4.0的一部分发布。当前版本的EF尚未准备好迎接黄金时段，并且由于一些奇怪的原因，微软决定不修补基本问题，而是将所有时间和精力投入到4.0上。这个是否是一个有价值的竞争对手/替代L2S还有待观察。 （我只尝试了测试版1，并且遇到了与EFv1相同的问题;主要是生成的SQL查询不良的问题......（ex 1 ex 2 ex 3等等）