.NET データベースアクセス

現在、データベースアクセスの汎用クラスを作成しています。

データベースアクセス部分をプログラミングする方法として、下記のように色々な方法があります。
・カスタムエンティティを使用する。
・DataSetを使用する。
・DataSetを内包するカスタムエンティティを使用する。
それぞれメリット、デメリットがあり、システムやチームメンバーの習熟度により、どの方法を使用するか選択します。

前回のシステムではカスタムエンティティ取り入れた方法を選択しました。
しかしチームメンバーのほとんどがJava等のオブジェクト指向言語が未経験かつ.NET開発も未経験という方たちで、それぞれのPGが独自の方法でデータベースからデータを取り出し、独自の方法で更新しているという収集のつかない状態に・・・。そして開発が一段落ついた頃、外注PGは自社に戻り、派遣PGであった私が全体の保守を行うことになりました。本当に厳しく辛い日々でした。

そしてPGである私は設計者に「設計ルールの必要性」を解くことから始まりました。設計ルールの必要性はすぐに理解していただけました。
そのとき設計者が言ったことは
「今回のシステムで思った事だけど、業務アプリの場合はよほど酷いルールでなければ、それなりに動くものができる。ルールを作って守らす事が、後々の保守のためにも必要だ。」
（えっ！？今頃気づいたのですか？）

まず命名規則を決めました。
（過去記事にも書きましたが、ハンガリアン表記法の半導入です！！）
我流の例外処理の記述を決め
（過去記事にも書きましたが、なんでもかんでも例外キャッチ！！）
そして最も重要なデータベースアクセス部分のルール決めに突入しました。
紆余曲折があり長い時間をかけ色々と話し合いました。

個人的には型付データセットを使用した更新を勧めたのですが、「ウィザードで作成する」部分で却下されました。（正直な所、私もウィザードは好きではありません。が、せっかくNetが用意してくれる便利な機能を使わないのは勿体無いなぁと思います。）結局、落とし所を探って我流データアクセスロジックが決定しました。

Formと1対1となるようなクラスを作成する。（以降FormManagerクラス)
DBテーブルごとにクラスを作成する。（以降DbTableクラス）
FormManagerクラスの役割は
・Formに表示するデータを取得する。（SQLを作成し実行。）
・Formから受け取ったデータを各DbTableクラス単位に分割し、各DbTableクラスの更新処理を呼び出す。
・トランザクションを管理する。
DbTableクラスの役割は
・DB更新処理。
クラス間のデータの受け渡しには、簡易型付データセットを使用します。
これはウイザードで作成せずに、自前で用意します。

そして現在、上記ルールで作成したデータアクセス部分のサンプルを作成しています。
サンプルを作成してて思ったことですが
Netの場合はFormに表示する内容はVIEWを作成し、更新はストアドが一番いい
もちろん設計者には管理が大変なので却下されました。

いつか決定権が持てたら
VIEWとストアドでシステムを組んでみたいです。