クラスはシンプルが良い(DAO編)

DAOクラスの方針も大体似たような感じになる。ここで言うDAOはデータベースへアクセスして、検索したり、更新したりするSQLを発行し、その結果をAPIクラスに返すクラスの事。

・SQL等は使い回せるならできるだけ使いまわすが、無理にしなくても良い。
 →無理にしようとすると、結局使い方が複雑になってしまう。
・1つのメソッドでなんでもしようとしてはいけない。
 →融通効かなくなるから。引数なんかで条件分岐すると、いつか収拾がつかなくなる。
・戻り値として返すリストのインスタンスは都度生成する。
 →リストのインスタンスを使いまわすと、ろくな事にはならない。意図しない箇所でクリアされるとか。
・メソッドの引数や戻り値は、抽象的な方が良い。
 変更した時の影響範囲をできるだけ小さくできる(その努力ができる)。
・SQLの実行等には、できるだけログを残す
 SQLServerであれば、SQLプロファイラなんかがあるから良いとか言われそうだけど、いろんな開発(複数のプロジェクト)が同じDBを使うと、自分が実行したログを探すのも一手間になる。

抽象化は、Javaの世界ではよく言われてた事だけど、まあ、C#でも言える事ではないかと。
C#1.1時代なら、ArrayListよりはIListで、今(C#2.0~4)なら、List<>よりは、IList<>かな。
メソッドの中だけの話で言えば、List<>やDictionary<>でも良い。

IList<int> list1 = new List<int>(10);
list1.Add(1);
list1.Add(2);
list1.Add(3);

とするよりは、

List<int> list1 = new List<int>(10);
list1.AddRange(new []{1, 2, 3});

としたい。しかし、APIクラスとのインターフェースになるようなメソッドの引数や戻り値(特に戻り値)は、抽象的な方が良い。
IList<>を継承するようなクラスを自作するなんてこと、めったに無いんだけど、仮にそうなったとしても、コードを変更する範囲をできるだけ小さくできるというメリットがある。
IList<>を実装さえしていれば、返すクラスのタイプを変更しても、影響範囲(コードを修正する箇所)は小さくて済む。結果、テスト(変更箇所の動作確認)規模も小さくなって、バグを埋め込む(エンバグとかデグレとか)リスクを少なくできる。
それはそれとして、止むを得ない理由がない限り、いちいち自作して、自分の保守の範囲を広げようなんて事はしない方が良い。
なお、実行したSQLのログ出力は必須だ。できるなら

・実行ユーザのIPAddress
・実行ユーザ名
・実行日時
・実行されたDAOクラス名とメソッド名
・実行にかかった時間

を出力したいところ。
デバッグ時だけでなく、運用時にもこれらがあると、エラー発生箇所の特定に要する時間が減る。
あれ?シンプルがいいのネタじゃない?まあ、いいか。
スポンサーサイト
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0


この記事へのコメント

コメントの投稿

非公開コメント


サイドバー背後固定表示サンプル

当ブログに書かれたソースコードは流用自由です。

バグ、スペルミス等はありうる事です。

ご利用の際は自己責任でお願いしますm(_ _)m