【spring】ControllerからEntityの役割について
解決済
回答 2
投稿
- 評価
- クリップ 3
- VIEW 23K+
プロジェクトによって異なる場合もあるかもしれませんが、皆さんの認識を教えてください。
皆さんが開発される際は、Controller、Service、Dao、Dtoの階層(+utilityなど)をそれぞれパッケージに分けて開発するイメージでしょうか？
またそれぞれの階層の担当は以下で合っているでしょうか？
・Controller
urlとマッピングするメソッドを作成する。
プログラマーが主に作る一番上の階層。
ここにはなるべく処理を書かない。
Viewの指定をする。
・Service
Controllerから呼ばれる。
ここにデータアクセス以外のロジックを書く。
・Dao
Serviceから呼ばれる。
データベースやファイルにアクセスするメソッドを書く。
ここでjdbctemplateやDbUtilsなどを呼ぶ。
・Dto=Entity=bean
データベースやファイルから取得したデータを保持するためのオブジェクト。
Daoで取得したデータを保持する。
カラムに対応したフィールドとそれに対するsetter、getterを持つ。
単純なvalidateメソッドなら持たせてもいい。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+2
役割はあなたの認識で合っていると思います。
しかし、きちんと分けるかどうかはシステムの規模や性質によると思います。小規模システムなら区別しなくてもいいと思います。
大規模システムの場合は意識しなければいけない場合があります。大規模システムの場合、サーバーを数十台とか数百台で運用するわけですが、その場合に1台の時と同じ構成・役割のサーバーを単純に並べる場合もあれば、役割で分割することもあります。大事なのは役割で分割する場合です。
つまり大規模なシステムではControllerとServiceのサーバーが異なっている場合があるのです。Controllerのサーバーではリクエストを受け付け処理結果を返すだけ。ServiceのサーバーはControllerに要求された処理を行いその結果を返す、という感じで。
当然、ControllerとServiceは通信が発生します。ので、何度もServiceを呼び出すとその回数分のネットワーク通信が発生するクソシステムになりますので、そうならないようにServiceで結果をまとめて返すようなコードを書くようになります。
例えば、特定の条件に合うユーザー一覧を表示する際に、まずユーザーリストをとって、その各ユーザの付加情報を別のテーブルからとってきてあわせて出力するとします。もちろん、DBで2つのテーブルをJOINして結果を返すDaoを作ることが最も望ましいのですが、めんどうなので既存のDaoだけを組み合わせて作ることはよくあります。
その際に、Controllerでまずユーザーを取得するServiceを呼び出し、さらに付加情報を取得するServiceをユーザー数分ループして呼び出すとすると、最初にとれたユーザーの件数によっては大変な量のネットワーク通信が発生することになるわけです。
なのでControllerにはServiceを呼び出すループは書いてはダメで、「ユーザーを取得するServiceを呼び出し、さらに付加情報を取得するServiceをユーザー数分ループして呼び出す」Serviceを作り、ControllerからはそのServiceを1回呼ぶようにすべきです。
という感じで大規模システムの場合、必然的にControllerとServiceの役割が明確に区別され、どちらで処理をさせるか悩むことは少なくなります。
一方で
実際に実装してみると、結局ControllerにDB以外の処理を実装してしまい、
Serviceですることがなくなって（Daoを呼び出すだけ）しまいました。
Controllerにどこまで処理を入れるか悩みどころですね。
こんな場合には、Serviceをなくしてしまってもいいと思います。
さらにページ数が20-30ページしかないし、アクセス数も少なくかつ将来も大量のアクセスが発生する心配のないようなシステムだったら、極論言えばJSPにSQLを書いてしまってもいいと思います。ユーティリティクラスはいくつか作ることにはなると思いますが、Controller・Service・Daoはなしで。そうすれば管理するファイルの数も減り、ほとんどの修正でコンパイルのし直しもしなくてよくなりますのでメンテナンスも簡単です。
規模に応じて適切な構成を考える、それが重要ではないかと思います。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
大体の認識としてはそんなものかと。
「Dtoそのものをレスポンスとして返すのではなく、加工した構造体を返したい」
場合は、上げられた分類の他にViewModel(ViewObject,Vo)を作成することもあります。
DaoからEntityを取ってきてService層でViewModelに加工してController経由でViewに返すイメージですね。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.33%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2016/04/29 12:40
>つまり大規模なシステムではControllerとServiceのサーバーが異なっている場合があるのです。Controllerのサーバーではリクエストを受け付け処理結果を返すだけ。ServiceのサーバーはControllerに要求された処理を行いその結果を返す、という感じで。
そんなことがあり得るのですね。とても勉強になりました。
>さらにページ数が20-30ページしかないし、アクセス数も少なくかつ将来も大量のアクセスが発生する心配のないようなシステムだったら、極論言えばJSPにSQLを書いてしまってもいいと思います。
今実装してるのはかなり小規模ですが、勉強もかねてcontrollerからdao、dtoまで律義に作っています。
しかもservice、daoに至ってはネットを参考にしてinterface化しているので小規模にしてはファイル数がかなり多いです。
Controllerからは基本はService
ひとつのみ呼び出す、
interfaceはやめてserviceとdaoをまとめる
を実施して規模に合った実装にしようと思います。