J2EE design decisions

J2EE design decisions(written by Chris Richardson)
http://www.javaworld.com/javaworld/jw-01-2006/jw-0130-pojo_p.html

■概要
 POJOs in Action（Manning Publications, January 2006） からの抜粋
 「Patterns of Enterprise Application Architecture」の考え方をJ2EEの世界をベースに、より実装に近い観点で論述された記事と考えてもらうとわかり易いかもしれません。新規性に富んだ話は多くはなかったですが、よく纏まった記事かと思います。

■要約
最近 POJOs、ライトウェイトフレームワークの話題が賑わせていますが、盲目的にそれを利用することは、EJB で犯した問題を繰り返すことになると警告しています。どんな技術でも強みと弱みがあり、それを理解してデザインを決定することが重要であると述べています。

大きく３つの選択肢があると述べています。

• EJB2 style
• POJO と ライトウェイトフレームワークの組み合わせ
• EJB 3

この記事では、デザイン決定のための５つの観点を指摘しています。

Decision 1: Organizing the business logic

• オブジェクト指向のアプローチか(Domain Model pattern)
• 手続き型のアプローチか(Transaction Script pattern)

Decision 2: Encapsulating the business logic

• EJB session facade(Figure 4.)
• POJO facade(Figure 5.)
• Exposed Domain Model pattern(Figure 6.)

Decision 3: Accessing the database

• JDBC directly（良い選択ではない）
     - 開発やメンテナンスは難しく、コストがよりかかる。
     - SQLのポータビリティの観点で欠けている
    - JDBCコードの記述は時間がかかり、エラーを起こしやすい
• object/relational mapping frameworks (such as JDO and Hibernate)
• SQL mapping frameworks (such as iBATIS)

Decision 4: Handling concurrency in database transactions

• Isolated database transactions
• Optimistic locking
    - テーブルにバージョンカラムを追加する方法が一般的
    - JDO や hibernate のようなフレームワークは Optimistic locking の機能を提供
• Pessimistic locking
    - 更新処理の最初に共有データをロックする方法
    - JDO は設定オプションとして Pessimistic Locking の機能を提供
    - Hibernate は locking object のためのプログラミング可能なAPIを提供

Decision 5: Handling concurrency in long transactions