こんにちは。

>例えば、OleDbを使用しているとするならばOleDbCommandに対しパラメーターを
>追加しなけばなりません。
>その場合に、業務ロジック側から作成するのであればOleDbCommandのスコープは
>最大限に拡げねばならなくなります。
引数の受け渡しなどを使用すれば、必ずしもスコープを最大限にまでする必要はないと思います。

>かといってデータベースクラスにパラメータクエリ用のメソッド等を用意した場合
>データベースのフィールドを直に指定しなければなりません。
業務ロジッククラスでパラメータを指定するようにしてもデータベースのフィールドを直に指定することは避けられないですよね？

>何か良い方法やパターンはありますか？
要するに、データベースの物理的な構造に影響されないようにするにはどうしたらよいか
ということを考えられているのでしょうか？

まず、今回のようにUI層(フォームクラス)と、ロジック層(業務ロジッククラス)とデータアクセス層(データベースクラス)で役割分担させてシステムを構築する場合、
データベースの物理構造に影響される部分は極力データアクセス層に記述することになっています(一般的には)。
このようにしておいて、データベースの物理構造の変更はデータアクセス層で吸収してUIやロジックはそのまま使いまわすことができるようになるのが理想です(が、実際にはデータベースの構造を変化させるときにはそれなりの要求があるのでなかなかデータ層だけで綺麗にはできません)。

データ層のプログラムも自分でデータベースのテーブル名やフィールド名を書くのではなく、できるだけ柔軟性をもたせ、開発作業も楽をするというのがここ数年のトレンドです。
たとえば、やや古い技術ですが型付データセットを使えば、データ層のプログラマはテーブル名やフィールド名を直接書く必要はなくなります。最近の技術ではADO.NET EntityframeworkやLink to sqlなどがあります。

ここからは私の意見ですが、これらの技術をつかっても裏では(大量の?)コードが自動生成され、そこにはテーブル名やフィールド名が埋め込まれています。GUIやウィザードでメンテできるので自分で書くよりは楽という意見もありますが、いざというときのトラブルシューティングが困難ですし、ブラックボックスを抱え込んでしまっているようでちょっと気持ち悪いです。規模の大小もありますが普通のシステム構築であればリリース前にコーディングレベルのトラブルの10個や20個は普通におきますよね。(コードは見られますので別にブラックボックスではないのですが、チーム全員が理解することを要求できない状態と思います。)
まとめると、これらの技術を使った場合
メリット：データベースの構造に変更があった場合、プログラム側でビルドエラーを検知できるようになるので、修正すべき箇所がすぐわかる。
デメリット：技術をちゃんと理解していないと何をすればいいのかわからない。チューニングやトリッキーな技がかなり使用しにくくなり、いざというときの壁になるときがある。


では、どうすればいいのかと言うと、あくまで私の意見ですが、
スタンス１
テーブル名やフィールド名などの物理構造は「できるだけ」データアクセス層に持たせるが、あまりそのことにこだわりすぎない。→再利用性は当然低下しますが、実際のところこの手のクラスはほどんと再利用しない。データベースの変更の影響での修正箇所は多くなり、しかもビルド時に検出されにくくなってしまいますが、テストでカバー。(どうせ、ウィザードで修正してもテストはします。)
メリット：直感的な開発。ベタな構造だがその分理解されやすくメンテできるシステムになる。
デメリット：工数がやや多い。テストが重要。

スタンス２
ある程度のテーブルはエンティティのようなクラスを作っておいて、プログラムからは間接的にのみアクセスできるようにする。ただし、そのことにこだわりすぎず必要であればためわらずテーブル名やフィールド名を直接指定する。あとはスタンス１と同じ。
メリット：スタンス１よりメンテの工数が節約できる可能性がある。(ビルドエラーでの検出もより多く可能になる。)。中のコードも比較的ベタなつくりになるので理解されやすい。
デメリット：ウィザードやデザイナを使って完全にエンティティ化するよりも工数がかかる。

ちょっと長く書きすぎました。こんな方向性の話しでよかったでしょうか？