ロジックとデータアクセスの分離って大事だと思うよ?

クラスはできるだけシンプルが良い(Logic編)
クラスはシンプルが良い(DAO編)
の続き的な話になるだろうか?

業務ロジックとデータアクセスのコードは分離した方が良いと思う

まあ、こんな事、@ITなんかの記事に嫌ってほどあったりするので、今更なんだけど、仕事で他の人が書いたコードを読む機会があり、業務ロジッククラスの筈のメソッド内で、「業務ロジック→いきなりSQL発行!→データ取得!そのままロジック再開」に突き進むなんてコードがあり、今更そんなコードを追っかけて分析とかすることになったので、げんなりしてしまったので、書いてしまった。せめてDAOクラス作ってくれよ!と言いたい。いや、作っているところもあるんだけど、徹底されていないというか、途中から分けるのがめんどくさくなった感がすごくある。
でも、既にリリースされてしまっているコードなんで、安易に変更できない。これが個人的であったり、限定的な人数で使用しているコードならそんな事はないんだけど。一度コードを変更してしまうと、
・影響範囲はどこまでになるか?
・動作確認はしたか?
・リリースをいつにするか?
等々、それだけでは済まなくなる。なので、追っかけて、悶えるだけになってしまった。
基本、業務ロジックはロジックだけ。データアクセスはデータアクセスだけの役割を持たせるべきとは思う。
ロジック側が必要なDAOクラスのインスタンスを生成し、必要なメソッドを呼び、必要なデータを取得する。どのようにデータを取得するかは、DAOクラスに一任する。ロジック自身は知らない。こうすることで、データ取得先に変更があったり、データの持ち方(構造)に変更があったとしても、ロジッククラスには影響しないと思う。
仕事では、

・ロジッククラスがどのDBにアクセスするか?はロジッククラス自身の属性として持たせる。
・接続先の情報は、configファイルに持たせる。
・DBの接続、トランザクションの管理は、専用のクラスを実装する。
・設定ファイル情報をもとに、専用のクラスインスタンスを生成する。
・ロジッククラスは、その管理クラスインスタンスを保持し、DAOクラスインスタンス生成時にそのインスタンスを設定する。
・DBの接続開始と終了、トランザクションの開始とコミット(或いはロールバック)は、共通(基底)クラスのメソッドが行う。
・ロジッククラスは、接続先DBやテーブルの物理名を属性以外で意識することはない。
・DAOクラスは、どのDBMSに接続しているかをできるだけ意識しない。

というところまではやっている。
仕事では、どうしても「動いてなんぼ」が優先されるんだけども、後々の事も含めてトータル的に考えてコーディングしてくれるように、啓発していくしかないんだろうな。
スポンサーサイト
当サイトは基本をすっ飛ばしてます。基本文法等は、@ITをどうぞ
カテゴリー: C# | コメント: 0 | トラックバック: 0


この記事へのコメント

コメントの投稿

非公開コメント


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

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

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

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