Hatena::ブログ(Diary)

出羽ブログ RSSフィード

Seasar Conference 2008 Autumn - 9/6(SAT), Tokyo

2008-07-07

S2AbstractServiceを用いたAction-Service-Logicパターン

| 12:11 | S2AbstractServiceを用いたAction-Service-Logicパターンを含むブックマーク

以前に「1.5階層のAction-Service-Logicパターン」を紹介させて頂きました。今回は、このアーキテクチャにS2AbstractService を導入した場合のアーキテクチャについて検討してみました。

主な変更点として、S2AbstractService を導入する場合は、アクションやロジックから直接JdbcManagerを使うこと得策ではないと考え、データアクセスロジックは全てサービスを経由するようになった点です。

まずは、アーキテクチャを図示したものをご覧ください。細かい解説は別エントリにて書かせて頂きますが、エンティティ単位のサービスを採用しつつも、ユースケース固有のロジックはアクションに記述する方法を提示したいと思います。


アーキテクチャレイヤ構成図)

f:id:dewa:20080707120108j:image


アーキテクチャモジュール相関図)

f:id:dewa:20080707120109j:image

xx 2008/07/08 10:41 流れないインターフェースですね

dewadewa 2008/07/08 11:36 > 流れないインターフェースですね

言われてみればそうですね(笑)。

重複対策として、共通処理を抽出してメソッド化すると
おっしゃるとおり「流れないインターフェース」の割合が増えますが、
これはプロジェクトの健全性をはかる一つの指標として良いかも知れないですね。

j5ik2oj5ik2o 2008/08/19 18:51 どーもですー。
サービスって必ずしもエンティティ単位で実装しないと思うのですが、
たとえばユースケース単位の場合は、エンティティを複数扱うかもしれません。その場合どのように実装していくのがスマートでしょうか?

dewadewa 2008/08/19 19:01 エンティティを複数扱う処理を自分はコントロールロジックと呼んでいるのですが、コントロールロジックがユースケース固有ならアクションに書く。ユースケースをまたぐ場合は、LogicなどServiceとは別の名前のクラスに書くのが良いと思っています。(個人的にはServceが別のServiceを呼ぶやり方は、相互依存が怖いので避けています。)

j5ik2oj5ik2o 2008/08/19 19:18 http://ml.seasar.org/archives/seasar-user/2008-July/015087.html
最近はエンティティに1対1がServiceと読んでいるのですね。。。知りませんでした。昔のユースケース単位のServiceをイメージしていたので食い違いがあったのだと思いますw
ActionやPageクラスにそのまま書く方向で検討してみます。