アプリを作成するときは、System.Dataインターフェイス（IDbConnection、IDbCommand、IDataReader、IDbDataParameterなど）を使用します。これは、ベンダーの依存関係を減らすために行います。簡単なテストアプリをやっていない限り、相談するときは倫理的なことのように思えます。
ただし、表示されるすべてのコードは、System.Data.SqlClient名前空間クラスまたは他のベンダー固有のクラスを使用しているようです。雑誌や本では、これをMicrosoftの影響力と、SQLServerに対してのみプログラムするためのマーケティングスピンに簡単に当てはめることができます。しかし、私が見るほとんどすべての.NETコードがSQLServer固有のクラスを使用しているように見えます。
ベンダー固有のクラスにはより多くの機能があることに気付きました。たとえば、SqlCommandオブジェクトにパラメーターを追加するのは1つのメソッドですが、IDbCommandにパラメーターを追加するのは4行以上のコードです。しかし、再び; これらの制限のために少しヘルパークラスを書くのはとても簡単です。
また、SQLServerが現在のターゲットクライアントである場合のインターフェイスに対するプログラミングは、すぐには必要ないため、過剰に設計されているのではないかと思いました。しかし、インターフェイスに対するプログラミングのコストが非常に低いためだとは思いませんが、ベンダーの依存関係を減らすことで大きなメリットが得られます。
ベンダー固有のデータクラスまたはインターフェイスを使用していますか？
編集：以下の答えのいくつかを要約し、それらを読んでいる間に私が持っていたいくつかの考えを投げ入れます。
ベンダーの中立性のためにインターフェースを使用する際に考えられる落とし穴：
- SELECTステートメントに埋め込まれたベンダー固有のキーワード（私のins、upd、delはすべてprocにあるので、問題ありません）
- データベースを直接バインドすると、おそらく問題が発生します。
- 接続のインスタンス化が一元化されていない限り、とにかくベンダー固有のクラスを呼び出す必要があります。
インターフェースを使用する前向きな理由：
- 私の経験では、（行使されていなくても）別のベンダーに移動する能力は、常に顧客から高く評価されてきました。
- 再利用可能なコードライブラリのインターフェイスを使用する