使用 LinqToSql 的 Winforms 应用程序架构

Question

我正在启动一个新的 Winforms 应用程序，并且我一直在我的 DAL 中使用传统的 ADO.NET 方法(...是的，硬编码!)

我以前在很多场合使用过 Linq，但更多的是用于临时 查询，所以我有一些使用它的经验，而且我喜欢它编写查询代码的简单性。我可能想要做的是用纯 LINQ 查询替换我现有的 DAL。我知道他们可能对此感到担忧，这就是为什么我需要你的帮助。

如果我必须像过去那样做一些事情，我会像这样构建我的应用程序:

• [AppName].ClientUI --> 桌面客户端表示层
• [AppName].WebUI --> 网络表现层
• [AppName].DAL --> ADO.NET 数据访问层
• [AppName].BLL --> 业务逻辑层(验证、额外计算、+ 管理器类)
• [AppName].BE --> 包含业务对象和集合类的业务实体

老实说，我一直在网络应用程序中使用它，之前从未做过 n 层 Winforms 应用程序。

如果我想用 LINQ 方法替换旧的 DAL 方法，我将面临哪些挑战。

最后，是否建议在多层应用程序中使用 LINQ？有时我认为使用旧的 ADO.NET 方法仍然更好……工作更多，但更好。我的意思是 - 如果我错了请纠正我 - 所有这些新技术的核心(旨在使我们作为开发人员的工作更好)不是都在使用传统的 ADO.NET 吗？？？

希望有人能对此有所启发! :)

Answer 1

对于直接连接到数据库的直接 winforms 客户端应用程序，Linq 是 ADO.NET 的一个很好的替代品，您会遇到很少的问题。使用类似 SQLMetal 的工具(或者内置 VS2008 的设计器)来生成你的 Linq 数据对象和数据库连接类。如果你想使用生成的对象作为你的“BE”对象，你可以复制这些东西并将它移动到你想要的任何程序集中(如果你想分离程序集)。或者，您可以只提供单独的“业务实体”和一个转换层，该转换层将数据从 BE 复制到 Linq 生成的对象，然后再返回。

我在使用 Linq 时遇到的一个问题是，它对断开连接的体系结构没有很好的支持。例如，如果您想将 DAL 放在服务器上并让所有客户端应用程序连接到它，如果您只是让 linq 对象在服务器上传输，就会遇到问题。

如果您确实选择拥有单独的业务实体(或具有断开连接的架构)，您会发现您必须仔细管理断开 Linq 对象与数据上下文的连接，然后在您准备好保存/更新时重新连接它们。值得先在这方面做一些原型(prototype)设计，以确保您了解它的工作原理。

另一件经常让人们感到困惑的事情是，linq 查询不会立即针对数据库执行，它们仅在需要数据时执行。请注意这一点，因为如果您不期望它，它可能会捕获您(并且在调试时很难发现，因为当您在调试器中查看您的 linq 查询时，它会执行以获取数据)。

还值得考虑将 Entity Framework 作为 linq2sql 的替代品(您仍然可以使用 linq2EF 查询)。 EF 是一个更完整的 ORM，更好地支持将相关表映射到多个对象，但仍然对断开连接的应用程序支持不佳。 .net 4.0 中的 EF 应该对断开连接的体系结构有更好的支持。