9

我从一个 SQLServer 数据库开始。所以看起来我应该使用System.Data.SqlClient命名空间。但是，我们可能会关闭 SqlServer 数据库并转到 MySql 或 Oracle。出于这个原因，我提出了一套关于我们的 .Net 应用程序如何与数据库通信的标准，以便将来在需要时更容易迁移到不同的数据库系统。

所以这里是标准：

  1. 尽可能使用 ORM（例如 NHibernate）（没有 LINQ，因为它只支持 SqlServer，但是实体框架及其对 Oracle 和 MySql 的支持呢？）
  2. 如果 ORM 是一种过度杀戮，那么使用参数化 SQL 查询。
  3. 仅将存储过程用于需要在数据库上执行的长时间运行或复杂的操作。

这让我想到了我手头的主要问题。 我应该使用哪个命名空间来编码我的 DAL？

在我看来，选择在System.Data.ODBC和之间System.Data.OleDB：

  • 有哪些取舍？
  • 一个比另一个更受欢迎吗？
  • 您对前 3 个标准有何看法？
4

7 回答 7

3

System.Data.SQLClient

仅连接到 SQL Server 2000 及更高版本，但在连接到这些数据库时您将获得最佳性能。

System.Data.OledbClient

连接到 SQL 6.5

OLEDBClient 使您能够连接到其他数据库，如 ORACLE 或 Access。但是对于使用 SQL Server，您将使用 SQLClient 获得更好的性能。

注意：为了连接到 ORACLE，微软也有 ORACLEClient。

System.Data.ODBCClient

仅使用 ODBC 驱动程序连接到旧数据库。（例如 MS Access 97。）

原始来源

于 2015-08-02T12:38:20.780 回答
2

您想使用 SQL Server 驱动程序。我了解您要做什么，但是您要完成支持多个数据库的方法是插入另一层抽象。您可以通过多种方式做到这一点。但是您将特定于数据库的代码放在类层次结构的边缘。因此，每个类都可以获得数据库特定功能的好处，但更高级别的调用者不知道也不关心下面使用的是什么数据库。至于 ORM，我更喜欢LLBLGen，但这只是我的偏好。

另外，澄清一下，LINQ 并不特定于 SQL Server。那就是LINQ-to-SQL。LINQ 是一种查询技术，可以在 LINQ-to-SQL、LINQ-to-Entities、LINQ-to-objects 中使用，甚至 LLBLGen 都支持 LINQ。

于 2009-06-01T22:26:10.647 回答
2

无论您现在使用 SQLClient 还是 Odbc，如果您使用存储过程或其他特定于数据库的功能，则在更改数据库引擎时都必须重写它们。

于 2011-05-06T12:53:29.743 回答
1

如果 DAL 发生更改，我将只使用 SqlClient 并重新编写/重新生成 DAL。

除非您现在要在多个平台上实施和测试，否则我不确定现在的额外努力是否重要或是否比重做 DAL 的努力以及您拥有 DAL 的事实无论如何，您已经将所有内容放在一个地方以供以后更改。

于 2009-06-01T22:25:31.177 回答
1

如果您有任何迹象表明您将交换数据库（或支持多个后端），那么 ORM 就是要走的路。否则，您仍然需要重构/重写大量 DAL 以支持更改。如果您的应用程序很小，它不会很糟糕，但是任何实质性的东西都会让您受到伤害。

于 2009-06-01T22:31:47.937 回答
1

您会发现使用 SQL Server SqlClient 比 OleDB 和 ODBC 开发更快、更容易 - 除非您极有可能需要支持多个平台，否则您会发现好处大于需要重写的风险你的 DAL。

此外，使用 OleDB / ODBC 只是维护平台独立性的一种方式 - 您可能会发现拥有多个 DAL 实现更有效，每个实现都使用所用平台的本机客户端。

于 2009-06-01T22:43:00.440 回答
0

我听说它说除非它是一个关键特性，否则你不应该太担心维护平台独立性。也就是说，

SQLClient 将为您提供本机访问权限，并且应该具有更高的性能（它不必进行任何抽象/翻译）。

要使 OLEDB 与 ODBC 相比，您唯一需要更改的是您的连接字符串。OLEDB 具有更多的客户端智能，因此它提供了更好的性能。

于 2009-06-01T22:33:26.730 回答