« | »

ん？POJOじゃないの？

PetStore 2.0 ea1内で使われているCategoryクラスのコードの冒頭は，以下のような感じ。

package com.sun.javaee.blueprints.petstore.model;

import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public class Category implements java.io.Serializable {
　　
　　private String categoryID;
　　private String name;
　　private String description;
　　private String imageURL;
　　
　　public Category() { }
　　
　　@Id
　　public String getCategoryID() {
　　　　return categoryID;
　　}
・・・

import文に思いっきりJava Persistece APIが登場している。全然POJOじゃないじゃん。当然import文を消すと，@Entityや@Idといったアノテーションが見つからないというコンパイルエラーになる。注釈って単なるマーカー(というか単なる文字列情報)だと思っていたが，これではべったり対象のAPIに依存してしまっている。
うーん，いかがなものか。HIbernateの永続化モデルクラスにすっかり慣れてしまった僕には，かなりの違和感を覚えたコードである。

[追記: 2006/08/04]
EJB3.0 Persistence API（JSR-220）で規定されているアノテーションをO/R-Mappingの領域で標準としましょう，という動きがあって，HibernateもHibernate Annotationでこれを採用しているらしい。つまり，J2EEコンテナ上でEJB3.0やJPAは標準なんだから，エンティティを扱うための抽象的な@Entityや@Idなどのためのimport文が埋まることは問題ない，っていう解釈なのだろう。
完全なPOJOであれば，アノテーションが付いていても，J2EEコンテナ外での動作，つまりEJB3.0やJPAのライブラリがなくても使えるようになっているのが必要とされると思うのだが，そうではないようだ。Javaのアノテーションは，ことJ2EE向けのものについては，POJOに対するこだわりはなく，あくまでEoDのためってことなんだろうな，きっと。

Posted:
08.04.2006
Category:
PetStore

Trackback URL:



  1. Miyazima より:
    %Y年%m月%d日 %H:%M

    どもです。個人的な意見をひとつ。
    純粋なPOJOかどうかは、個人的にはどうでもよいと思ってます。
    POJOにして再利用性が高まるとも思っていないし、
    そもそも再利用した覚えがあまり無いｗ
    （Strutsなら）Action⇒Service⇒DAOというレイヤー構成で、
    Serviceを再利用可能にしても、実際に再利用した覚えがないですね。
    DAOとEntityは統一すべきだと思います。
    純粋なPOJOであることで、単体のテスタビリティは上がるかも知れませんが、まあ大したことないかなと。
    大規模開発だと、再利用を考えてレイヤーを分けて、レイヤーごとに開発者ロールを分けて
    単体テストをきっちりさせるという考え方がありますが、
    結局画面～データアクセスまで同じ人が設計・実装する方が生産性が高いので、
    そこまでやる意味あるのか？と思い始めてます。
    僕の経験上、大規模になればなるほどテスタビリティを上げても、誰も思った通りテストしてくれなかったりします。
    この辺まで来ると、もはやアーキテクチャだけでは解決できず、
    プロジェクト管理やガバナンスと言った視点が必要になってきます。
    ロジックに関してはトランザクションスクリプトが、保守の観点から見ても一番良いかなと思う今日この頃です。
    もちろんコードの重複は良くないので避ける必要がありますが、影響範囲が掴み易いのは間違いないです。
    今後は再利用というよりは、統一とか統合という観点で同じコードを書かないアプローチを目指そうかなと思っています。
    もうあんまりコード書かないけどｗ
    ちなみに、ある案件でEJB3、JPAを使うことで検討してますが（ていうか既に導入決定）、結局JPAだけじゃ足りなくてHibernateのアノテーションが入りまくる結果となりました。
    やっぱりHibernate＆Tools便利だね、ということでした。
    長くなっちゃいました。トラバにすればよかった。ごめんなさい。

  2. よういちろう より:
    %Y年%m月%d日 %H:%M

    Miyazimaさん，どもです。(^^
    POJOの再利用性は，うん，おっしゃるとおり。再利用なんてしたことないですね。ただし，VOというか，DTOというか，そういった情報しか持たないオブジェクトについては，どこか特定のレイヤに属する訳ではないので，気持ち的にPOJOに近いほうがいいかな，と。情報しか持たないオブジェクト＝単に値の入れ物，としか思っていないからですね，僕が。その入れ物に情報を入れる側がよろしく処理すればいいので，入れ物に特定の実装は許せん，って感じでしょうかねー。
    レイヤごとに人を当てるか，業務機能単位で人を当てるかは，賛否両論でしょうね。僕は前者です。専門性がでてきて初めて，単体テストの作成も期待できるようになるのかな，と。全員が均一にシステムで採用したアーキを理解できるとは思えない，という前提が僕にはあります。
    あらま，結局JPAじゃ足りないんですねぇ。うーん，Hibernate，やっぱりいいですよねぇ。楽だもんなぁ。
    毎度毎度，Hibernateで楽するか，自作自動生成ツールで吐くDAOで頑張るか，悩みます。。。

Get Adobe Flash playerPlugin by wpburn.com wordpress themes