EJB3時代のアーキテクチャパターン 業務ロジックType1
EJB3、JSF、JPAを使ったときに業務ロジックはどのように実装すればよいのでしょうか。
- Type1:ManagedBeanに業務ロジックを書く
最初は、ManagedBean(多くの場合Action)に業務ロジックを書くパターンです。
- TransactionServletFilter
- Action(プレゼンテーションロジック、業務ロジック、データアクセスロジック)
- EntityManager(ActionにDI)
- Entity
で構成されます。EntityManagerを使ってDBにアクセスし､後はすべてActionで処理します。
TransactionServletFilterは、(おそらく)フレームワークで提供され､EntityManagerは、JPAの実装から提供されるので､開発者が書くのは､ActionとEntityになります。Entityは、近いうちにツールで自動生成することがほとんどになってくると思われるので､開発者が実際に書くのは､Actionだけになるでしょう。
クラスを1個だけ書けば良いので､シンプルで素敵!!!なわけありません。Type1の問題点は次のとおりです。
- プレゼンテーションロジック、業務ロジック、データアクセスロジックがActionに集中するので､クラスが肥大化してメンテナンスが困難になる。
- 業務ロジックがViewごとに実装されるので､同じようなロジックが複数のViewに分散する可能性がある。
- Viewごとにロジックを実装する場合､自分が開発していないViewのことは、ほとんど気にかけないため、他のViewで同じようなロジックが実装されていても気付かない。
- データアクセスのロジックが個別に実装されるので､同じようなロジックが複数のViewに分散する可能性がある。
どっちもかなり問題であり､Type1を使うのはお勧めしません。登場するクラスが少なければ､シンプルで良いんだみたいな単純な意見を言う人がたまにいるようですが､もちろんそんなことはありません。それぞれ、適切に役割分担されているのが良い設計なのです。
