Service を使う際の方針
TeedaでService を使う場合で、以下のどちらの案が良いか迷っています。
たぶん、迷っているってことは、どれも決定的ではないということなはず。6/29にも説明するつもりですが、私の考えは次のとおりです。
- プレゼンテーションロジック(画面表示のためのロジック)は、Pageクラスに実装する。
- その画面に閉じたビジネスロジックは、そのPageクラスに実装する。
- 同一ユースケース(サブアプリケーション)の複数の画面で使われるロジックは、各画面の共通の親Pageクラスに持たせる。
- 複数のユースケースで使われるロジックは、共通のユースケースを抽出し、共通のユースケース名Serviceクラスに持たせる。
まとめると、プレゼンテーションだとかビジネスロジックだとかは気にせずに、画面固有のロジックはその画面(Page)に、ユースケースで共通に使われるロジックはユースケース共通のPageクラスに、複数のユースケースで使われるロジックは、共通ユースケース用のServiceクラスに持たせるということです。
ビジネスロジックには、DBFluteのConditionBeanの組み立ても含まれます。
従来の常識(?)だと、プレゼンテーション、ビジネス(ドメイン)、データアクセスは、別の層に分けることが望ましいとされていました。理由は、それぞれ役割が違うから。プレゼンテーションとビジネスの間にサービス層をおくパターンもあります。
層と層は、インターフェースでつなぐのが良いとされているので、もうクラスいっぱい、おなかいっぱい。
ロジックをどこにおくのかが明確になっていれば、メンテナンスはしやすいはずなので、層にこだわるのは、もうやめたほうがいい。以前は、プレゼンテーション層のクラスにロジックを置くとテストしにくいという問題がありましたが、Teedaの場合、PageもPOJOなので、テストしにくいという問題はありません。
Serviceクラスには、Entity(DTO)、非永続的な引数を渡すことになるでしょう。
このやり方だと、Pageクラスが大きくなる可能性がありますが、大きくなるのは、ロジックが多い場合でしょう。ロジックが多いクラスが大きくなるのは、特に問題ないと思います。メソッドが適切に分割されていればOK。
もう難しく考えるのはやめましょう。いまどきのアプリは、ロジックはあまりないはず。
