質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Q&A

5回答

20016閲覧

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

ryo_se

総合スコア68

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

0グッド

0クリップ

投稿2015/07/14 02:39

私は現在、主に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をインスタンス化して使いまわしています。

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答5

0

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に該当するクラスが含まれています。

投稿2015/07/14 03:34

編集2015/07/14 04:32
eripong

総合スコア1546

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

eripong

2015/07/14 03:53

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

2015/07/14 04:19

追記しました。
ryo_se

2015/07/15 02:00

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

退会済みユーザー

2018/03/21 23:59

トランザクション管理としてスプリングつかうならスプリングだけで良くないかとおもってる。 前時代(spring3だったかな)にアクション(コントローラー)が弱かったときにフレームワーク連携をしていただけですし。 そんなこんなでフレームワーク連携ライブラリーがspringからstruts側に移動した。
guest

0

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

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

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

投稿2018/03/21 15:59

nekt

総合スコア38

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

投稿2016/03/31 11:28

thesecret11

総合スコア234

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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クラスは画面遷移とパラメータの授受、エラーメッセージの出力をまかせることが可能です。参考までに。

投稿2016/03/31 06:54

A-pZ

総合スコア12011

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

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

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

参考になれば・・・

投稿2015/07/14 12:14

iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

ryo_se

2015/07/15 01:51

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

2015/07/15 02:13

そうですね。誤更新については、DAOとLogicがテーブルの行の項目をオブジェクト化したものをやり取りすれば、Logicで誤った代入をしない限り問題はありません。 全項目設定は確かに手間はあります。しかし、それぞれの項目は1回だけ指定すれば済みます。個別にUPDATE文を書くならば、すべての項目について”1回以上”指定することにいなります。 DBを他のシステムと共有していないのであれば、全項目UPDATEのほうが手間がかからないです。 とはいえ、テーブルの数が多くなるとなかなかの手間でこれを解決するために、各種フレームワークがあります。私はJavaのフレームワークについてはほとんど知りませんが、eriponさんの回答はその点もカバーしているフレームワークなのかなと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問