EJB3、JSF、JPAを使ったときのアーキテクチャは､ある一定のパターンで説明できると思っています。私見ですが､説明したいと思います。 まず、プレゼンテーション層であるJSFですが、ページ(View)ごとにManagedBean(s)を定義します。ManagedBeanの作り方は3パターンあり イベント処理専用(Action)でモデルとしてはEntity(ドメインモデル)を使う(Action only) イベント処理とプレゼンテーションモデルを兼用(Page only。Pageでイベントも処理) イベント処理(Action)とプレゼンテーションモデル(Page)を分離(Action + Page) があります。 私は､ドメインモデルは､ドメイン層でのみ使い､プレゼンテーション層では､専用のプレゼンテーションモデルを使うべきだと思っています。なぜなら、ドメイン層とプレゼンテーション層では､
「Type2:Serviceに業務ロジックを書く」でも、同じようなロジックが複数のViewに分散する問題は以前未解決のままです。それを解決しようとするのがこのTypeです。 Type3:Entityに業務ロジックを書く Viewごとに業務ロジックを書けば､分散してしまう可能性がありますが､Entityにロジックを書けば､分散の危険性が減ります。なぜなら、Entityを利用するときに､既に似たようなロジックがないか探すことができるからです。 TransactionServletFilter Action(プレゼンテーションロジック) Dao(データアクセスロジック。ActionにDI) EntityManager(DaoにDI) Entity(業務ロジック) 開発者が書く必要があるのは､Action、Daoのインターフェース、Daoの実装、Entityに対する業務ロジックの実装です。 プレゼ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く