java Webアプリケーション開発におけるlogicとdaoの切り分け

Question

私は現在、主にstruts2でjavaのWebアプリケーション開発を行っております。

基本的に開発する際、データの流れは下記のようにして作っているのですが、
最近データベースアクセス関連の構成で悩んでおります。

画面 → action → logic → dao → logic → action →画面

・前に行っていた構成
action ... connectionを取得。logic,daoに受け渡して一つのコネクションを使いまわす。
logic ... データの整形などを行い、SQL文などは記述せずDBアクセスはDAOに一任
dao ... 各SQL文を記載し、ここでDBからデータを取得しlogicに返す。各機能ごとに個別のDAOが存在。

しかし、logicでdaoにアクセスし、返されたデータをそのままactionに返すといったパターンが多かったり、各機能におけるDAOの作成にかかる工数などを考えて最近は下記のようにしています。

・現在の構成
action ... connectionを取得。logic,daoに受け渡して一つのコネクションを使いまわす。
logic ... データの整形メソッド及び、SQL文を記載した各種データアクセスメソッドを記述
dao ... DBアクセスする際のUtilメソッドのみ記載したベースファイル一つのみ

一つの機能であまりにもDBアクセスするメソッドが多くなる場合はそれ用のDAOを作成してますが、
基本的にはこのような構成としています。
また別機能で他のlogicで書いたSQLを使用するときは、そのlogicをインスタンス化して使いまわしています。

実際工数はかなり短縮されたのですが、このような構成で今後も開発を続けていいのかふと疑問に思いました。
皆様のご意見、及び普段どのように開発しているかご教授していただければ幸いです。

Answer 1

Action、LogicにDaoが持つべきDBへのアクセスに関するSQLなどを含ませるのは、
役割が不明確になり望ましくないので、Logicに含めることはありません。
開発効率化のためには、フレームワークを使う方がよいと思います。

Struts2ですと、自前でコネクションを取り回さず、
他のフレームワークと組み合わせて作ることが普通かと思います。

Spring+MyBatisとの組み合わせがよくあるのでは無いでしょうか？
例えば、以下のサイトで紹介されているような方法です。
Struts 2にトランザクション管理を提供する「Spring Frameworkプラグイン」
[mybatis]MyBatis+SpringをStruts2で使ってみた

一つ目のサイトは古いので、MyBatisでなくその前身のiBATISです。

追記

[ 2755 ] [Struts2]Spring3+MyBatisの組み合わせ
ここにあるstruts2spring3mybatis.zipにはserviceとして、logicに該当するクラスが含まれています。

Comments

[eripong]

Actionから直接Daoを呼び出しており、ちょっと例が適切ではないので、他を探してみます。

[eripong]

追記しました。

[ryo_se]

ご返答ありがとうございます。

ソースを少し確認してみたのですが、struts2と他のフレームワークを組み合わせたことがないため理解するのに時間がかかりそうです・・。
参考文献をもとに勉強してみます。

[退会済みユーザー]

トランザクション管理としてスプリングつかうならスプリングだけで良くないかとおもってる。

前時代（spring3だったかな）にアクション（コントローラー）が弱かったときにフレームワーク連携をしていただけですし。
そんなこんなでフレームワーク連携ライブラリーがspringからstruts側に移動した。

Answer 2

ちょっと話から外れて、DAO周りの実装についてですが、Strutsから渡ってきたリクエスト情報をさばくのはActionの層でそれはお手製必須の部分かと思いますが、DBアクセス関連はDoma2などのORMapperの導入などは検討できそうでしょうか。

特にプロジェクト内でのポリシーやルールに問題がなければ、DAOに当たる部分のクエリ操作やEntity変換については、既にいろいろなライブラリで機能が提供されています。そういったものを導入するのは中身のブラックボックスな部分に不安が残るかもしれませんが、複数人で開発されているもので、動作もある程度安定しており、利用する側の開発コストは大幅に減らせるものかと思います。

IcqlやDoma2やReladomoなど、いくつか用途別の物があるかと思いますので、検討されてはいかがでしょうか。
以上蛇足でした。

Answer 3

Javaのこの手のアーキテクチャって頭でっかちで、このクラスの役割は・・なんて最初は考えるのですが、ただ値を受渡してるだけのオブジェクトをやたらに作りがちですね。

一度、MVCとか忘れて、画面にそのまま書くとか、画面とactionだけにしてみるとか、ごっそり削ってみてはいかがでしょうか。最低記述量で済んでいない部分があるとすれば、なんで、そうなってるのだっけ？と考えてみたほうがいいかと思います。

Answer 4

記事のご紹介ありがとうございます(・ω・)

Struts2のActionクラスにてデータベースへ接続をしてもよいのでが、どちらかといえばActionクラスはHTTP層との橋渡しと、画面遷移を担うクラスで、他のロジック、例えばデータベースとのデータの授受やファイルの出力は別のクラスにて行う方が、Actionクラスの負担が減ります。

Struts1時代とは異なり、2系は、リクエストパラメータなどの入力項目はすべてActionクラスが主担当になります。このためActionクラスはとても大きくなりやすいでしょう。
またStruts2は標準でデータベースアクセスの機能は持ち合わせていませんので、別途仕組みが必要です。そのためStruts2はさまざまなフレームワークを利用できるようプラグインが用意されており、例えばO/RマッピングフレームワークであるMybatisを使ってデータベースとのデータのやり取りを行うとした場合、Mybatis-Springプラグインを使ってSpringにトランザクション管理を実施させることができ、さらにStruts2-Springプラグインを使うことで、Struts2はSpring管理のクラスを扱うことができます。
こうすることで、ActionクラスからSpring管理のクラス(Serviceクラス)を経由し、ServiceクラスからDAO(=Mybatis直接でもいいですし、別途DAOクラスを作ってもよい)の構造が作れますので、Actionクラスは画面遷移とパラメータの授受、エラーメッセージの出力をまかせることが可能です。参考までに。

Answer 5

Logicが薄くなってしまうのは、DAOが厚すぎるからではないかと予想します。以下の説明はそれを前提に行うので、外れていたら悪しからず。

DAOまたはSQLにロジックが含まれていると、本来書くべきlogicで記述する内容がないことになります。DAOでは、本当にデータの呼び出しと更新（いわゆるCRUD）のみとするべきです。

それを考えるとDAOから得られるデータは、基本的には全項目で加工なしで出力します。
更新SQLも、キー以外の全項目を更新することにすると、ロジックが排除できます。利用しないデータもDBとやり取りすると実行速度がかかってしまうことを心配になりますが、その代りにLogicが集中するので可読性・再利用性が高まります。

逆に実行速度が問題になる場合は、DAOにロジックを作りこむ必要があります。
DAOにロジックを作りこむ代表的な例としては、特定のキーのデータ件数を調べるなど集計関数を含むSQLがあります。ただし、統一性を考えるなら、実行速度の問題が出ない限りさけるべきでしょう。

私がDAOを作る際はテーブルへの挿入・更新・削除の3つのSQLと選択用のいくつかWhere句の管理のみのを持つようにします。
例外として、子レコードのカウントを行うSQLや、更新日時などログとして残しているデータは他では利用しないのでDAOで付加してます。

参考になれば・・・

Comments

[ryo_se]

ご返答ありがとうございます。

＞更新SQLも、キー以外の全項目を更新することにすると、ロジックが排除できます。
この部分ですが、更新に関してはDAOにUPDATEメソッドを一つだけ用意し、更新する際は全カラムを更新すると認識しています。
ですがこの場合、誤更新や全項目の値を指定しなければならない手間が懸念されないでしょうか？

私の認識違いでしたら申し訳ございません。

[iwamoto_takaaki]

そうですね。誤更新については、DAOとLogicがテーブルの行の項目をオブジェクト化したものをやり取りすれば、Logicで誤った代入をしない限り問題はありません。
全項目設定は確かに手間はあります。しかし、それぞれの項目は１回だけ指定すれば済みます。個別にUPDATE文を書くならば、すべての項目について”１回以上”指定することにいなります。
DBを他のシステムと共有していないのであれば、全項目UPDATEのほうが手間がかからないです。

とはいえ、テーブルの数が多くなるとなかなかの手間でこれを解決するために、各種フレームワークがあります。私はJavaのフレームワークについてはほとんど知りませんが、eriponさんの回答はその点もカバーしているフレームワークなのかなと思います。