【spring】ControllerからEntityの役割について

Question

プロジェクトによって異なる場合もあるかもしれませんが、皆さんの認識を教えてください。
皆さんが開発される際は、Controller、Service、Dao、Dtoの階層(+utilityなど)をそれぞれパッケージに分けて開発するイメージでしょうか？

またそれぞれの階層の担当は以下で合っているでしょうか？
・Controller
urlとマッピングするメソッドを作成する。
プログラマーが主に作る一番上の階層。
ここにはなるべく処理を書かない。
Viewの指定をする。

・Service
Controllerから呼ばれる。
ここにデータアクセス以外のロジックを書く。

・Dao
Serviceから呼ばれる。
データベースやファイルにアクセスするメソッドを書く。
ここでjdbctemplateやDbUtilsなどを呼ぶ。

・Dto=Entity=bean
データベースやファイルから取得したデータを保持するためのオブジェクト。
Daoで取得したデータを保持する。
カラムに対応したフィールドとそれに対するsetter、getterを持つ。
単純なvalidateメソッドなら持たせてもいい。

Answer 1

役割はあなたの認識で合っていると思います。
しかし、きちんと分けるかどうかはシステムの規模や性質によると思います。小規模システムなら区別しなくてもいいと思います。

大規模システムの場合は意識しなければいけない場合があります。大規模システムの場合、サーバーを数十台とか数百台で運用するわけですが、その場合に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はなしで。そうすれば管理するファイルの数も減り、ほとんどの修正でコンパイルのし直しもしなくてよくなりますのでメンテナンスも簡単です。

規模に応じて適切な構成を考える、それが重要ではないかと思います。

Comments

[lupus_dingo]

詳細な回答ありがとうございます。

>つまり大規模なシステムではControllerとServiceのサーバーが異なっている場合があるのです。Controllerのサーバーではリクエストを受け付け処理結果を返すだけ。ServiceのサーバーはControllerに要求された処理を行いその結果を返す、という感じで。

そんなことがあり得るのですね。とても勉強になりました。

>さらにページ数が20-30ページしかないし、アクセス数も少なくかつ将来も大量のアクセスが発生する心配のないようなシステムだったら、極論言えばJSPにSQLを書いてしまってもいいと思います。

今実装してるのはかなり小規模ですが、勉強もかねてcontrollerからdao、dtoまで律義に作っています。
しかもservice、daoに至ってはネットを参考にしてinterface化しているので小規模にしてはファイル数がかなり多いです。
Controllerからは基本はService
ひとつのみ呼び出す、
interfaceはやめてserviceとdaoをまとめる
を実施して規模に合った実装にしようと思います。

Answer 2

大体の認識としてはそんなものかと。

「Dtoそのものをレスポンスとして返すのではなく、加工した構造体を返したい」
場合は、上げられた分類の他にViewModel(ViewObject,Vo)を作成することもあります。
DaoからEntityを取ってきてService層でViewModelに加工してController経由でViewに返すイメージですね。

Comments

[lupus_dingo]

回答有り難うございます。
画面表示用に加工するための層をつくるということですね。

実際に実装してみると、結局ControllerにDB以外の処理を実装してしまい、
Serviceですることがなくなって（Daoを呼び出すだけ）しまいました。
Controllerにどこまで処理を入れるか悩みどころですね。

[yohira0616]

Controllerの役割としては、「Serviceで取ってきたmodelをViewに渡すだけ」とするのが理想だと思うので、データベースから取ってきた値をそのまま渡すだけならServiceはDaoを呼び出すだけの薄いクラスになっても大丈夫だと思います。

[lupus_dingo]

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

「Serviceで取ってきたmodelをViewに渡すだけ」を意識して実装しようと思います。