我正在开始一个新的Winforms应用程序，我总是在我的DAL中使用传统的ADO.NET方法（...是的，硬编码！）
我以前在很多次点上使用过Linq，但是对于 adhoc 查询更多，所以我对它有一些经验，我喜欢编写查询代码是多么容易。我想做的或是用纯LINQ查询替换现有的DAL。我知道他们可能会对此感兴趣，这就是我需要你帮助的原因。
如果我不得不做过去一如既往的事情，我会构建我的应用程序：
说实话，我总是在网络应用程序中使用它，之前从未使用过n层的Winforms应用程序。
如果我想用LINQ替换旧的DAL方法，我将面临哪些挑战。
最后，是否建议在多层应用中使用LINQ？有时我认为使用旧的ADO.NET方法仍然更好...更多的工作，但更好。我的意思是 - 如果我错了，请纠正我 - 所有这些新技术的核心（旨在使我们的工作更好的开发人员）是不是他们仍然使用传统的ADO.NET ???
希望有人能够对此有所了解！ ：）
答案 0 :(得分：2)
我已经两种方式完成了。
你是对的，手动滚动ADO.NET DAL是更多的工作，那么你是否可以获得额外工作的性能优势？是的，当您使用Linq to SQL类时，您将从顶部获得大约7％到10％的开销。但是，对于这么小的开销，你会获得很多好处：
当然，如果你不需要任何这些东西，那么Linq to SQL可能看起来很奢侈。但是，我发现Linq to SQL更容易维护，特别是因为如果数据库发生更改，可以重新生成DAL类。
是的，Linq to SQL使用了ADO.NET。
Linq to SQL的多层故事不太清楚，很大程度上是由于DataContext对象需要处理的方式。我建议查看这个CodePlex项目：
Linq to Sql的多层体系结构示例
http://www.codeplex.com/MultiTierLinqToSql
答案 1 :(得分：2)
对于直接连接到数据库的直接winforms客户端应用程序，Linq是ADO.NET的一个很好的替代品，你会遇到很少的陷阱。使用SQLMetal之类的工具（或VS2008内置的设计器）生成Linq数据对象和数据库连接类。如果你想使用生成的对象作为“BE”对象，你可以只复制这些东西并将其移动到你想要的任何程序集（如果你想分离程序集）。或者，您可以只提供单独的“业务实体”和转换层，将来自BE的数据复制到Linq生成的对象，然后再返回。
我曾经多次遇到Linq的一个问题是它对断开连接的架构没有很好的支持。例如，如果您想在服务器上安装DAL并将所有客户端应用程序连接到服务器上，那么只要让linq对象在服务器上传输就会遇到问题。
如果您确实选择具有单独的业务实体（或具有断开连接的体系结构），您将发现必须仔细管理从数据上下文中断开Linq对象，然后在准备保存/更新时重新连接它们。首先要在这个领域做一些原型设计，以确保你了解它是如何工作的。
经常让人们兴奋的另一件事是linq查询不会立即针对数据库执行，它们只在需要数据时执行。请注意这一点，因为如果你不期待它可能会让你失望（并且在调试时很难发现，因为当你在调试器中查看你的linq查询时它将执行以获取数据）。
同样值得考虑将Entity框架作为linq2sql的替代方案（您仍然可以使用linq2EF查询）。 EF是一个更完整的ORM，并且更好地支持将相关表映射到多个对象，但仍然受到对断开连接的应用程序的不良支持。 .net 4.0中的EF应该对断开连接的体系结构有更好的支持。