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