EJB3時代のアーキテクチャパターン 業務ロジックType4

「Serviceに業務ロジックを書く」も「Entityに業務ロジックを書く」も結局問題を抱えています。それを解決するのがこのTypeになります。

• Type4:EntityとEntityFacadeに業務ロジックを書く

Entityに業務ロジックを書いた場合

1. 業務ロジックで自分と関連の無いEntityのデータを必要としたときに､どのように取得するのか。
2. 複数のEntityを処理するメソッドをどこに置くのか。

という問題がありました。これらの問題を解決するのがEntityFacadeになります。EntityFacadeはEntityと一対一で作成します。業務ロジックを呼び出したい場合､Entityのメソッドを直接呼び出すのではなく､EntityFacadeのメソッドを呼び出すようにします。Entityは引数で渡します。
処理がEntity内で完結している場合は､EntityFacadeは、Entityにその処理を委譲します。
直接自分と関連の無いEntityのデータを必要とする場合は､EntityFacadeが必要なデータを取得した上で､Entityのメソッドの引数で必要なデータを渡します。これで、Type3の最初の問題を解決することができました。
複数のEntityを処理するメソッドもEntityFacadeに置けば良いのです。これで、2つめの問題も解決することができました。

• TransactionServletFilter
• Action(プレゼンテーションロジック)
• EntityFacade(Entity単独で処理できない業務ロジック)
• EntityManager(EntityFacadeにDI)
• Entity(Entity単独で処理できる業務ロジック)

開発者が書く必要があるのは､Action、EntityFacadeのインターフェース、EntityFacadeの実装、Entityに対する業務ロジックの実装です。Daoは省略しています。その場合でも､データアクセスロジックは､EntityFacadeに集約されているので､分散する危険もありません。
一般的なEJB3時代のアーキテクチャは､このType4で良いのではないかと思います。