ボクはテーブル名やフィールド名とかは、データ層ではなく、
ビジネスロジック層に分類しています。業務モデル化した
時点でこれらは決定され、データベースとはほぼ１：１対応、
後からフィールド名やテーブル名を変えることはまずありません。
変更はビジネスロジック層に依存していると思います。

そう考えると
>例えば、OleDbを使用しているとするならば
.NET Framework 上で三層アーキテクチャの話をするなら、
データベース層は本当に接続のみだから OleDb そのもので
いいのでは？汎用性あるでしょう？そのままで。
>その場合に、業務ロジック側から作成するのであればOleDbCommandの
>スコープは最大限に拡げねばならなくなります。
ない。既存のクラスで言うなら OleDb がフィールド名を参照できる
スコープで定義されないと動かないとか。。。これはない。
パラメータで受け渡せば済む事。

それに対して具体的なパラメータを設定するのは、一般に
ビジネスロジック部分で、汎用性とか言っても、マスタメンテと
実績入力なんて共通化する意味はないでしょう。むしろほぼ同じ
ロジックでも、発注と売上で税計算の適用が違うなど、敢えて
別にすべき場合さえ発生します。
業務モデルの構造次第なのだから、汎用性を求めること自体
少ないです。
>で、さらにおっしゃられているデータベースの構造の変化時や僅かなテーブル構造の
>変化が発生する等は普通にありえる話ですから全てが綺麗にとは言い切れません。
実際に経験の蓄積があるのだから、それを分析すべきでしょう。
僅かなといいつつ、フラグのフィールドなんかが追加になってたら、
それはもう業務ロジックが変わっているのでは？
データ層の修正のみに収まりそうな事例があったなら、もう少し
具体的なサンプルデータを出してもらえませんか。

三層構造が特に重要視されるWEB アプリでも、ビジネスロジック
層はアプリケーションサーバ上に置かれる事が多いと思います。
ここは特に重要で、WEB アプリの場合、データベースの構造及び
業務ロジックに関する情報はサーバ外に漏れないようにします。
アプリケーション層との完全な分離ですね。
セキュリティ面と、修正が発生した場合に、その範囲をサーバ内
に収める為です。
アプリケーション層とビジネスロジック層の分離で悩む事は多い
ですが、データ層は本当に既存クラスで収まると思ってました。

> エンティティクラス
必要だとしても、DataRow あたりで十分だと思うんですが。。。

> Oracleが多いのでチューニングが行い難くなると致命的かもしれません。
これも、よくある実行計画の分析なんかだと、SQL そのものが
がらりと変わる場合があると思います。下手にデータ層に
入れ込まないほうが良いんじゃないかなぁ。

クラス作るより先に、既存クラスをもっとよく見るべきかも。
ほぼそのまま利用すれば良いものも多いのでは？
究極の汎用的ってのは、自作クラス数０の事だと思います。