我是 ADO.NET 的新手，我对可用于处理数据的选项的数量感到有点困惑和沮丧。有常规的 ADO.NET、LINQ to SQL、实体框架。
现在我正在开发一个 IRC 客户端并使用 ADO.NET（和 SQLite 提供程序）来存储网络、服务器、收藏频道等设置。
我如何决定使用哪个？
编辑：我认为我应该提到的另一件事是将设置“绑定”到 GUI 以便编辑和管理它们。例如，一个设置对话框，左侧是 TreeView 中的网络和设置，右侧是用于编辑它们的文本框。
【问题讨论】：
首先，Linq-to-SQL 仅适用于 Microsoft SQL Server - 所以在您的情况下，该选项立即不在窗口中。
接下来，我想你真的需要决定你的数据访问有多棘手和多复杂。
如果您主要处理几个表，每个表包含几列，并且您需要来回读取和写入一些信息，那么您最好使用标准的直接 ADO .NET（诸如 ADO.NET 连接和执行 SQL 查询的命令对象之类的东西）。在这种情况下，由您来处理关系模型（数据库中的行和列）与您的应用程序中的对象之间的所有“转换”——这有点繁琐，有时还需要重复编码- 但它可以工作，对于简单的场景来说相当容易，并且为您了解 ADO.NET 的内部工作提供了最佳基础（如果您对它相当陌生）。
ADO.NET 实体框架和 Linq-to-Entities 是完全不同的野兽——而且要复杂得多。当你有非常大的应用程序时，它真的很出色，你的数据库中有几十个或数百个表，你的应用程序中有一个庞大且可能复杂的业务对象模型，并且你需要支持各种后端（SQL Server、Oracle、Postgres 等）。 ）。 EF 允许您在设计器中定义对象（您的“客户”类及其属性）和数据库中的关系存储（您的“客户”表及其列）之间的映射，并且 EF 将处理很多为您在表和域对象之间进行映射是一项繁重的工作 - 但肯定还有很多东西要学习。
因此，在您的情况下，对于一个相当简单的应用程序，我绝对建议现在只使用普通的旧 ADO.NET，以了解其中的原理并了解它是如何工作的。在你的情况下，我不认为走 EF 路线值得麻烦和学习曲线。
马克
【讨论】：
我真的不明白你为什么需要 ADO。为什么不直接使用 .NET 的内置设置持久性框架？这会自动将您的设置存储为每个用户的 XML 文件。
【讨论】：
对于您正在进行的轻量级工作，我认为带有 SQLite 提供程序的 LINQ 将非常适合。
详细说明：
如果您正在做一个数据量很大的应用程序，ADO.NET 可能是您最好的性能与可用性。
但是，如果您需要执行高级操作，例如从多个数据源进行查询、业务层验证或审计注入，那么 Entity Framework 可能是您的最佳选择。
【讨论】：