【MVC】コントローラとサービスの切り分け

Question

わからないこと

• ControllerとServiceの切り分けが分かりません。
• 下記に簡単な例を示しましたので、どの方法がベストか、他の方法が良いか、ご教示いただきたいです。
• (そもそもRepositoryを直接コントローラから実行するのって普通ですか？Serviceを経由する必要はないですか？)

処理概要(細かいところは省きます)

1. テーブルaのデータを取得
2. 取得できなかったら処理終了
3. テーブルbのデータ取得
4. DTOにaとbのデータをセット

コード

※現在springを使用しているため、javaおよびspringで記載します。

パターン1:全部Serviceで処理(同一のDTOを構成する処理はまとめるという思想、ただ関連テーブルが増えるとserviceのメソッド内の処理が膨大になります・・・)

@Controller
public Class hogeController{
	public hogeDto search(){
		return hogeService.getDto();
	}
}

@Service
public Class hogeService{
	public hogeDto getDto(){
		aEntity = aRepogitory.findOne(1);
		if( aEntity == null ){
			return null;
		}
		bEntity = bRepogitory.findOne(1);

		hogeDto.setHoge(aEntity.hoge);
		hogeDto.setFuge(bEntity.fuga);

		return hogeDto;
	}
}

パターン2:全部Controllerで処理(多分この程度の処理なら許容されそうですけど、もっと膨大になったらだめですよね・・・？)

@Controller
public Class hogeController{
	public hogeDto search(){
		aEntity = aRepogitory.findOne(1);
		if( aEntity == null ){
			return null;
		}
		bEntity = bRepogitory.findOne(1);

		hogeDto.setHoge(aEntity.hoge);
		hogeDto.setFuge(bEntity.fuga);

		return hogeDto;
	}
}

パターン3:値のセットはControllerで処理、後はServiceで実装(データ操作はすべてServiceを経由、データ操作に不随してロジックもついてたらこれですかね・・・・？)

@Controller
public Class hogeController{
	public hogeDto search(){
		aEntity = hogeService.getA();
		if( aEntity == null ){
			return null;
		}
		bEntity = hogeService.getB()
		hogeDto.setHoge(aEntity.hoge);
		hogeDto.setFuge(bEntity.fuga);
		return hogeDto;
	}
}

@Service
public Class hogeService{
	public hogeDto getA(){
		aEntity = aRepogitory.findOne(1);
		if( aEntity == null ){
			return null;
		}

		return aEntity;
	}
	
	public hogeDto getB(){
		return bRepogitory.findOne(1);
	}
}

どうあるべきか、ご意見お聞かせいただけたら幸いです。

Answer 1

MVCというよりSpringMVCについての回答となりますが、
コントローラからServiceクラス（@Serviceアノテーション付加）のメソッドを呼び出した際にトランザクションが開始されますので、
トランザクション管理したいものをServiceクラスに実装し、不要なものはコントローラ層で実装すればよいです。

1.テーブルaのデータを取得
3.テーブルbのデータ取得

とありますが、これは同一トランザクションで取得すべき内容でしたら
両方とも同一Serviceクラス（の同一メソッド）内に記載すべきです。
※SharedServiceを利用して分割する方法もありますが割愛します

以下が参考になるかと。
http://terasolunaorg.github.io/guideline/5.5.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html

Answer 2

とのことですが、基本形・理想形はどういった形式で、どういう状況で変化するのでしょうか？

理想形かどうかはわかりませんが、一つの指針ならあげられますので参考にしてみてください。

各クラスの役割

• コントローラークラス

画面からのイベントを受け取ってサービスを呼び出す

• サービスクラス

リポジトリを呼び出してデータの取得、ドメインクラスを呼び出す

• ドメインクラス

業務のデータの保持と、ルールを記載するクラス
リポジトリは呼び出さずに業務ルールだけに専念する

流れ

サービスは言い換えるとユースケースと言えます。
例えば自動販売機でジュースを買う場合、以下のように考えられます。

• コントローラ

「自販機のボタンを押す」というイベントをうけて
自販機サービスの「ジュースを買う」を呼びだす

• サービス

ジュースの情報（ドメイン）を取得

• ドメイン

金額やジュースの残量、冷え具合などの状態を持っているので、
「まだジュースは残ってるか？」
「冷えて出せる状態か？」
「投入されたお金は本物か？」
「金額は足りてるか？」
などのルールを判定する
また、ルールには判定だけじゃなくて、このジュースの場合は
シールをつけるみたいな業務ルールのロジックも組み込みます
※自販機ではそういうことはないですが

• サービス

ドメインのルール判定の結果、問題なければコントローラーに結果を返す

• コントローラー

サービスの結果をもとにジュースを出す

設計方法

作る前に上記のルールを考えておけば、設計段階で

• 画面からのイベント
• ユースケース
• 業務ルール

以上を押さえた資料を作成すればバックエンドのプログラムは作れると思います。

その他

サービスクラスがオブジェクト指向っぽくなりませんが、
そこは仕方ないと割り切って作ります。
例えば、「自動販売機サービス」なのに持っているメソッドは「ジュースを買う」っておかしな感じになっちゃってます。

Answer 3

プログラミングの世界には「ファットコントローラ」という概念があります。
ファットコントローラ撲滅運動というスライドが作られるくらい、忌み嫌われるものです。

そもそもオブジェクト指向では「役割分担」をきちんとすることが理想とされています。はじめのうちは何でもかんでもコントローラに全て書いてしまいがちです。
ただ、それでは可読性もメンテナンス性も悪くなります。

そのために細かい役割分担をすることで「道具を用意して適宜使う」ような形にするわけですね。
1個軽い道具を作れば他でも使いまわしがききます。

サービスとは・・でいうと使っているフレームワークや言語、もしかしたら現場で概念がちょっとずつ違うかもしれませんが、一般的には下記に現れるようなものと思っていいと思います。

• MVCモデルにおけるサービスの役割について教えて下さい
• 社内勉強会でサービスクラスがなぜ存在するのかについて紹介しました
• MVCモデルとは#Service

基本はビジネスロジック部分を切り出したもの・・・という理解ですね。
コントローラはあくまでリクエストを受けて、レスポンスを返すだけに終始し、その間の処理部分はサービスに任せる。

どこまでどう切り出すかは状況次第とは思います。
サービスもあまりコントローラに特化したものでないほうが良いとは思います。

Comments

[HelloWorld2]

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

> どこまでどう切り出すかは状況次第
とのことですが、基本形・理想形はどういった形式で、どういう状況で変化するのでしょうか？

> ファットコントローラ
パターン2は基本形でないことはわかりました。

また、コントローラから(サービスを経由せず)リポジトリを呼び出すことは問題ないのでしょうか？

[m.ts10806]

デザインパターン
で調べてください。