よういちろうより

よういちろう — Sat, 05 Aug 2006 01:27:49 +0000

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

Miyazima より

Miyazima — Fri, 04 Aug 2006 11:16:37 +0000

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

ん？POJOじゃないの？ へのコメント

よういちろう より

Miyazima より

ん？POJOじゃないの？へのコメント

よういちろうより