[PukiWiki]
第1回J2EE/DI/Aspectパターン勉強会議事録
http://patterns-wg.fuka.info.waseda.ac.jp/st/index.php?%5B%5B%C2%E81%B2%F3J2EE%2FDI%2FAspect%A5%D1%A5%BF%A1%BC%A5%F3%CA%D9%B6%AF%B2%F1%B5%C4%BB%F6%CF%BF%5D%5D

[ リロード ]   [ 新規 | 編集 | 差分 | 添付 ]   [ トップ | 一覧 | 単語検索 | 最終更新 | バックアップ | ヘルプ ]

最新の20件
2008-03-172007-07-072007-07-032007-06-222007-03-132005-10-172005-09-272005-09-262005-06-302005-06-29

[ J2EE/DIコンテナ/AOPパターン・プロジェクト ]

第1回J2EE/DI/Aspectパターン勉強会

  • 日時: 2005年7月14日 19:00-
  • 場所: 豆蔵
  • 参加者: 伊藤さん,比嘉さん,中島さん,竹端さん,久保さん,鹿糠さん,関野さん,荒浪さん,太田さん,鷲崎さん,赤坂さん,藤井さん,松信さん,江川さん,長谷川

活動期間と取り組み方

  • 3ヶ月単位で、4ヶ月目にパターンWG勉強会で途中成果の報告
  • 取っ付きやすいものから

最初の3ヶ月におけるテーマ案

  • 本当に良いの?DI/AOPで本当に保守性や拡張性が上がるの?根拠は?
  • 定義ファイルの管理は?複数のチームで開発する時とかどうするの?
  • DIコンテナ(+ AOP)の利用〜成功パターン、アンチパターンは?
    • 問題領域としてのドメイン
    • 設計
    • 管理
  • スキルセットは?OOの知識とかいるの?
  • アスペクトのデザインパターン
  • ツールを調べよう どんな便利なツールがあるの?
  • 他の言語(.NET、Rubyなど)と比べてみよう

最初のテーマ「DIコンテナの利用、設計」に決定

  • PofEAA の解説 -- 長谷川さん
  • Domain Model 対 Transaction Script

Domain Model

  • ロジックとデータを統合
  • 仕様変更時のロジック変更に弱い。DIコンテナでも解決困難。
  • ロジックを可変にしようとするとStrategyパターンになる・・・
  • しかし、O/Rマッパーでオブジェクトを対応付けて生成するので、DIコンテナによるオブジェクト生成が効き難い
  • AspectJ, AspectWeltz?のような、静的/クラスローディング時でのクラス定義変更が、DIコンテナにおけるオブジェクト生成時でどうように可能であれば・・・
  • 複数のドメインオブジェクトの相互作用を必要とするフロー系のロジック(アプリケーションロジック)がService Layerに、個々のドメインオブジェクトごとに完結したプリミティブなロジックがDomain Modelにそれぞれ分けて配置されていれば、DIコンテナによるロジック変更が可能だろう。
  • しかし、その切り分けは難しいだろう。どうせ下はDAO、O/Rマッパー。
  • そもそも、Domain Modelで持たせるべきメソッドはあまりないのでは?
  • だったら、最初からTransaction Script+DAO、O/Rマッパーで良いのでは?
  • ステートレスなサービスはDIコンテナで扱いやすいだろう。ステートフルなサービスは別に・・・
  • 使うDAOの変更など。
  • 用いるDAOの仕組みによっては、例えば、更新処理などについてインタフェースを変更せざるを得ない。

Transaction Script

  • 仕様変更時のロジック変更に強い。DIコンテナで解決容易。

アスペクトの成功パターン、アンチパターン

  • トランザクション、ロギング、例外ハンドリングしか聞かない・・・
  • ロギングについては、デバッグレベルでのロギングにはアスペクトは使わない方がいい。ある箇所/部分に特化したものであり、横断的関心事ではないため。
  • Mix-in の考え方は、Javaにはない。しかし、フルスペックのアスペクトでできるようになったときに、果たして使われるようになるだろうか?
  • まだあまり使われていないので、アンチパターンは無い
  • あるいは、トランザクション等以外でアスペクトを使おうとすることが、アンチパターン

次のDIコンテナが目指すところ: あらゆる実行時点でのDI

  • 例えば、フィールドアクセスや特定メソッドへのアクセスの時点で、DIする仕組みがほしい。もしそれができれば、Domain Model中のロジックについて変更もできるだろう。

結論

  • どの設計でも、DIコンテナはOK
  • アスペクトはトランザクション等でのみOK
  • アスペクトでもパターンは重要という話になるだろう。パターンが無いと危険。

次回開催

  • 次回は定義ファイルの管理について:サンプルを長谷川が用意
  • 開催日は追ってご連絡差し上げます

リロード   新規 編集 差分   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: Tue, 03 Jul 2007 06:53:01 JST (3792d)
Link: DI(3788d)

Modified by Hironori Washizaki

"PukiWiki" 1.3.4 Copyright © 2001,2002,2003 PukiWiki Developers Team. License is GNU/GPL.
Based on "PukiWiki" 1.3 by sng
Powered by PHP 5.3.3

HTML convert time to 0.012 sec.