私が参加したいくつかのチーム (私たちが行っていたことをすべて覚えているわけではありません。かなり前のことです) では、データ層の CRUD メソッドをコーディングするときに、SqlDataReader の代わりに IDataReader を使用していました。
アーキテクトが常に IDataReader を好んだ理由を誰か教えてもらえますか?
その理由は、インターフェースへのコーディングに関係していますIDataReader。一方、 にコーディングした場合SqlDataReaderでも、コードを移植して Oracle などで使用するのは簡単かもしれませんが、その信頼性は低くなります (移植も行う必要があります)。
IDataReader抽象化であり、具体的な型を強制するのではなく、契約します (つまり、 CRUD 操作を実行します)。拡張性とテスト容易性の目的で、インターフェイスへのプログラミングが推奨されます。
依存関係をインターフェイスで表すと、ユニット テスト(実際の実装の代わりにモック オブジェクトを提供する場合) や非運用環境(さまざまな実装での作業など)で、依存関係をより簡単に変更できます。
追加の調査として、依存性注入やSOLID 原則に関連するその他の概念を確認することをお勧めします。
それはばかげている。データ レイヤー全体を変更する必要がある可能性は比較的低いですが (これはかなりのコストがかかるため)、追加のレイヤーをサポートする必要がある可能性はかなり高くなります。次のシナリオを検討してください。
では、どうぞ。これは実際に私が取り組んでいるプロジェクトで起こりました。10 か月も経たないうちに、すべてがOracleから Oracle、MySQL、および SQLite に移行する必要がありました。確かに、これらの移行には常に追加の作業が必要でした (主に DB の違いによる) が、DAL コードの大部分は再利用されました。DAL が Oracle と緊密に結合されていれば、それは可能ではないでしょうか? そうなることは間違いありませんが、それにはもっと多くの時間と労力がかかると確信しています。
教訓 -常に成功のために計画を立てます。
The IDataReader はインターフェースだと思います。データベースアクセスを処理する多くのクラスを実装および処理しますが、SqlDataReader を使用する場合は、実際に IDataReader インターフェイスを使用する実装されたクラスですが、クラスに限定される代わりに、IDataReader を使用すると、データベースプロバイダーを実装して簡単に変更することができます。したがって、将来、データベース エンジンを切り替えたい場合でも、参照の書き換えを避けることができます。