使用IDataReader或SqlDataReader

Question

我所在的几个团队(不，我不记得我们都在做什么了，已经有一段时间了)在编写数据层CRUD方法时，使用IDataReader而不是SqlDataReader。

谁能告诉我为什么我们的架构师总是更喜欢IDataReader？

Answer 1

IDataReader是抽象的，不强制任何具体的类型，而是契约(即。执行CRUD操作)。出于可扩展性和可测试性的目的，最好使用。

使用接口表示依赖项使您可以更轻松地更改它们，无论是在单元测试中(当提供模拟对象而不是真正的实现时)，还是在非生产环境中(比如使用不同的实现)。

对于更多的研究，我建议看看dependency injection和其他与SOLID principles相关的概念。

为什么要更改数据层或完全替换数据库？

那太荒谬了。您需要更改整个数据层的可能性相对较低(因为这是相当大的成本)，但您需要支持额外的的可能性相当高。考虑以下场景：

• 客户希望在Oracle机器上运行一块软件，因为这是他们所拥有的，而他们不希望在服务器上运行任何额外的数据库。为实用起见，您永远不会公开DAL之外的Oracle位，但要保持干净，并将其编程为interfaces.
• Project，事实证明这足以吸引另一个客户。然而，他并不是那么有钱，而且正在运行MySQL机器--整个DAL现在必须在MySQL上工作，事实证明它在实现方面并不是特别困难(抛开甲骨文和MySQL的差异不谈)。大多数代码库是reused.
• Finally，作为负载平衡工作的一部分，Oracle客户端决定将一些计算委托给在主从模式下工作的不同机器(主是原始软件，调整为主从模式)。Slaves本质上是在旧的和慢的机器上运行的master的小版本。他们必须使用SQLite作为数据存储。

这就对了。这实际上发生在我一直在做的一个项目上，在不到10个月的时间里，从甲骨文到甲骨文，MySQL和SQLite都是我们需要的。当然，这些转换总是需要一些额外的工作(主要是由于DB的差异)，但是DAL代码的大多数都被重用了。如果我们的DAL与Oracle紧密耦合，这不是可能的吗？我相信它会的，但我也确信它会花费更多的时间和精力。

学到的教训-总是为成功的做计划。

Answer 2

原因与接口编码有关:如果使用IDataReader编码，则可以更好地确保以后需要切换到不同品牌的RDBMS。另一方面，如果您使用SqlDataReader编写代码，您的代码可能仍然很容易移植到Oracle，但是您会对此缺乏信心(而且您也必须进行移植)。

Answer 3

我认为IDataReader是一个接口。它实现并处理许多处理数据库访问的类，而如果您使用SqlDataReader，它是一个实现的类，它实际上使用IDataReader接口，但不限于类，IDataReader允许您实现并轻松地更改数据库提供程序(如果您将来决定这样做)，因此，如果您想要切换数据库引擎，则可以避免重写引用