質問: プロジェクトによって異なる場合もあるかもしれませんが、皆さんの認識を教えてください。 皆さんが開発される際は、Controller、Service、Dao、Dtoの階層(+utilityなど)をそれぞれパッケージに分けて開発するイメージでしょうか? またそれぞれの階層の担当は以下で合っているでしょうか? ・Controller urlとマッピングするメソッドを作成する。 プログラマーが主に作る一番上の階層。 ここにはなるべく処理を書かない。 Viewの指定をする。 ・Service Controllerから呼ばれる。 ここにデータアクセス以外のロジックを書く。 ・Dao Serviceから呼ばれる。 データベースやファイルにアクセスするメソッドを書く。 ここでjdbctemplateやDbUtilsなどを呼ぶ。 ・Dto=Entity=bean データベースやファイルから取得したデータを保持するためのオブジェクト。 Daoで取得したデータを保持する。 カラムに対応したフィールドとそれに対するsetter、getterを持つ。 単純なvalidateメソッドなら持たせてもいい。
回答: 役割はあなたの認識で合っていると思います。 しかし、きちんと分けるかどうかはシステムの規模や性質によると思います。小規模システムなら区別しなくてもいいと思います。 大規模システムの場合は意識しなければいけない場合があります。大規模システムの場合、サーバーを数十台とか数百台で運用するわけですが、その場合に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はなしで。そうすれば管理するファイルの数も減り、ほとんどの修正でコンパイルのし直しもしなくてよくなりますのでメンテナンスも簡単です。 **規模に応じて適切な構成を考える**、それが重要ではないかと思います。