5 DBアクセスとトランザクション
手:最近はSpringを使ってバリバリとコーディングしてるんですよ。
僕:そうか。僕は実践主義者だからいっぱいコーディングしてると聞くだけでうれしいよ。
手:でも、一人でコーディングしてると、本当に設計上これで良いのか悩みますよね。
僕:そういう悩みを持つのは良いことだよ。いくらいっぱいコーディングするのが良いと言ったって1メソッドに30000行詰め込むような実装をしてちゃ意味ないしね。そう言った意味では、設計上、実装上の悩みを解決してくれたり、注意してくれる仲間がいつ環境を作ることが重要だね。
手:そうですね
僕:じゃあ、早速今書いてるソースを見せてもらって、設計上の悩みを解決しようか。
手:了解です。このサービスクラスとDAOなんですが・・・。
------後輩はディスプレイにサービスクラスとDAOを表示する
僕:うんうん。これではせっかくのレイヤ化を台無しにしているよね。
せっかくSpringを利用して、インタフェースベースの設計を行ない、レイヤ間を疎結合にしたつもりでも、ちょっとしたことで、レイヤ化を台無しにしてしまうことがある。
たとえば、サービスクラスでSQL文(SQL文全体とまでいかなくでもWHERE節以下の条件文とか)を作って、DAOをわたしてしまうことがそれだ。
SQLをサービスクラスで作成してDAOに渡すようにしてしまうと、データアクセス層の実装をSQL文が不必要なORMを利用したDAOに変更する時にビジネス層のサービスクラスに変更が入ってしまう。
こうしたことを防ぐためには、SQL文を作成するようなデータベース関連の作業はデータアクセス層で行うようにして、ビジネス層から排除しなければならない。
同様にORM独自のException(たとえばHibernate独自のExceptionなど)をそのままビジネス層で受取ってしまうこともレイヤ化を台無しにしてしまうので注意しよう。
このように、レイヤでやるべきこと、やってはいけないことをしっかりと考えてクラスを設計・実装をするようにしなければ、せっかくSpringを使い、インタフェースベースの設計をしても意味がないのだ。
ただSpringやインタフェースベースの設計をすれば勝手にレイヤ間は疎結合になるという思い違いだけはしないでほしい。