EJB3時代のアーキテクチャパターン 業務ロジックType2
- Type2:Serviceに業務ロジックを書く
ManagedBeanに業務ロジックを書くパターンの問題点である「クラスが肥大化してメンテナンスが困難になる」を解決するのが､このTypeで、Actionから業務ロジックを分離して、Serviceで業務ロジックを実装します。ServiceはActionごとに用意され、実体はStateless SessionBeanになります。データアクセスロジックはDaoで実装して、Serviceクラスから利用します。DaoはEntityごとに用意します。DaoをEntityごとに用意すれば､データアクセスロジックを使いたい人は､最初に対象となるEntityのDaoをチェックするでしょうから、データアクセスロジックの分散を避けることができます。EntityManagerはDaoにDIします。
- TransactionServletFilter
- Action(プレゼンテーションロジック)
- Service(業務ロジック。ActionにDI)
- Dao(データアクセスロジック。ServiceにDI)
- EntityManager(DaoにDI)
- Entity
開発者が書く必要があるのは､Action、Serviceのインターフェース、Serviceの実装、Daoのインターフェース、Daoの実装です。クラス数は増えてしまいましたが､Actionの肥大化に問題、データアクセスロジックの分散問題は解決されました。
しかし、View:Action:Serviceは1:1:1の関係なので､「Viewごとに業務ロジックが実装されるので､同じようなロジックが複数のViewに分散する可能性がある」問題は､依然として解決されていません。
後､Daoの必要性については考えてみる必要があるでしょう。Daoがなければデータアクセスロジックが分散する危険性がありますが､小さなアプリケーションの場合､多少分散してもたかが知れているという考えもあります。以前のようにデータアクセスのフレームワークを隠蔽するという必要性は､JPAがデファクトになるので余り考えなくてもいいでしょう。ただし、メンテナンスのことを考えると、データアクセスロジックが分散しているより､ここを見れば分かるってなっていたほうが望ましいと思います。
