JavaコミュのＤＩコンテナについて語りませんか？

初めて掲示板出させていただきます。
某通信企業系のプロジェクトマネージャーを勤めております。
私のプロジェクトでは、springとかを使用せずに、独自のDI
コンテナを作成して、処理のディスパッチを行っています。
ただDIコンテナといっても世の中的にあるものは、全てclass
レベルでのディスパッチャーはあっても、メソッドレベルまで
におとした細かい動きをするディパッチャーってないですよね。
その辺でみなさんから、より良いご意見があればコメントお願い
します。
因みに私どもが提供している機能は以下

１、トランザクションの管理を行う（ステートレス）
２、プロセスIDによって、class#methodの呼出を行う。
３、１スレッド１インスタンスとなるような構造設計
　　ができるよう、抽象クラス群を用意している。

特に３については、これとコードテンプレートを用いる
ことにより（因みにIDEはeclipse3.0.2です）、かなり
の工数低減を図ることができました。
今後J2EE5とかを導入した際、アノテートとの併用も視野
に入れなければならないかと頭を抱えています。
みなさんのご意見お待ちしております。m(_ _)m

コメント(20)

最初
全て
最新の40件

[1] mixiユーザー 04月13日 18:02

DIコンテナについて語るのに大賛成です。

＞メソッドレベルまでにおとした細かい動きをする
＞ディパッチャーってないですよね。

Seasar2のS2Strutsなどは、メソッドレベルでのディスパッチに
対応していたと思います。

また、Seasar2ならOGNL式を使った注入も出来ます。

ところで、疑問ですが、

＞２、プロセスIDによって、class#methodの呼出を行う。
プロセスIDというのはJVMの起動しているプロセスのID
でしょうか?
だとすると、複数マシンでクラスタリングするとどうなるか、
疑問です。

[2] mixiユーザー 04月13日 19:02

＞yo4takaさん
Seasar2ですか。やはりそのキーワードがでてきますね。
私はまだ使ったことがないので、よくは分かりませんが、
こんごJ2EE5と連携したときに、どのような展開を見せる
のか楽しみです。
・・・私のプロジェクトでは、リッチクライアントな為
　　　HTMLベースの開発ができない・・・（＞－＜、）

言葉がたりませんでしたね。ごめんなさい。
ここでいっているプロセスＩＤとは、VMではなく、当該システム
開発にて定義したプロセスＩＤです。
通常業務基幹系システムとなると、画面に対してたくさんの
ボタンがつきます。そのボタンひとつひとつにＩＤを振るわけ
ですが、これがプロセスＩＤになります。

[3] mixiユーザー 04月13日 19:28

なるほど、ボタン押下に対するIDをプロセスIDと呼んでいたのですね。
失礼しました。

試していませんが、Seasar2もDI部分は、J2SE環境で動くと思います。

[4] mixiユーザー 04月14日 17:42

Seasar2のことは、よくはわからないのですが、私のチームが
提供している機能と、思想は同じかと考えています。
また、業務AP側にトランザクション管理を行わせると、想定外
な不具合が発生する可能性があるため、トランザクション管理
についても、コンテナ側で行う仕様となっています。
基本スタンスは、業務APから例外がスローされた時のみrollb
ackが行われると言う考え方です。
ゆくゆくは、EJBも視野にいれて、セッションステートフルでも
動作できるような仕組みを考えています。
EJB3になってから、サーブレットコンテナの一部として機能す
ることが出来るようになったため、つくりの上では、かなり楽
になるのでは、と考えております。
今私たちが、このDIコンテナを成長させるべく、J2EE5をター
ゲットにした開発を目指してます。
いかがでしょう？

[5] mixiユーザー 04月14日 18:10

> ２、プロセスIDによって、class#methodの呼出を行う。

どっちかというとJSFのメソッドバインディングに近いかと。DIコンテナそのものはインジェクトできる単位でしか物事をあつかわないのでメソッドレベルはサポートしないでしょう。そのラッパとしてメソッドバインディングを提供するのは素直な実装だと思います。

> ３、１スレッド１インスタンスとなるような構造設計
> 　　ができるよう、抽象クラス群を用意している。

抽象クラスの機能は、どうやって実装クラスに渡されるのでしょうか？DIの機能を使っているのであれば、そのテクニックは知りたいところです。それとも継承？

[6] mixiユーザー 04月15日 10:09

どーもです(^^)

S2は触ったことがないのですが、S2StrutsのメソッドレベルディスパッチというのはLookupDispatchActionともまた違うものなのです？

画面にボタンが増えてくるとこちらも面倒ではあるので、他にいい方法がないかと僕も思ってますね。

うちはトランザクションまわりはspring+hibernateにまかせていますねぇ。DBへのアクセスはどうされているのですか？

[7] mixiユーザー 04月15日 16:04

詳しくは、
http://s2struts.seasar.org/ja/s2struts.html#POJOAction
を参照してください。

S2StrutsはControl層のコンポーネント実装手段ですので、
DIContainerの機能ではないですね。
すみません。DIに釣られながら、話を逸らしてしまいました。

私はSeasar2に傾倒しているので、S2DAOを使っています。

ただ、DAOとロバストネス分析でいうエンティティは
レイヤーが違うと思っているので、
DAOの層の前にエンティティ層を設けると、
環境に依存しないインターフェースになるかなと思っています。

受注処理で
商品Aの受注量が100
商品Aの在庫数が1000

と、すると、

DAOのクライアントコードはDBを参照して1000を引っ張ってきて、
1000-100=900で、900をDBに書き込みます。

エンティティのクライアントコードは在庫-100って、
メッセージを投げるだけ、

勿論それに答えるDBを用いて実装したエンティティの実装コードは
DAOのクライアントのような実装をします。

で、このエンティティのインターフェースが
SOAやEJBのStatelessSessionBeanに対応する場所かなと、
考えています。

…、済みません。また、脱線した…、

[8] mixiユーザー 04月15日 17:48

＞yo4taka
時に脱線は新しい発見にもなったりするから
良いと思いますよ。
私自身まだDIコンテナのべき論にまではいたってないから
そうした周りをとりまくオブジェクションがかなり役に立
ちます。
話につながりのある脱線はみなさんどんどんしましょーー
(^o^)

[9] mixiユーザー 04月15日 19:45

S2も時間があったら手をだしてみたいんですよねー

うちのボスはどうも分散環境にアレルギーがあるらしくて、EJB3.0もまだ手を出せないでいますよ。

[10] mixiユーザー 04月16日 00:13

yo4takaさんはリッチクライアント開発を主としているみたいですね。
今のプロジェクトはC#で作る予定だったものをお客さんの都合で（たぶんお金）急遽Javaに変わって仕事が回ってきたんですが泣かされています。
画面設計がWebではあまり想像しない設計で、GUIでWebアプリケーションを開発できるツールを使うことを想定した設計だねってよく思います。C#使ったことないですが(^^;

そういう意味では、使ったことないんですが、S2＋S2JSFが近いものを実現しているのではないかなと思いますがどうでしょう？

[11] mixiユーザー 04月16日 00:42

画面設計が複雑な場合、気をつけたいのが、

- JavaScriptを使った細かい制御
- HttpSessionに入れるオブジェクトの消去

はっきり言って、全開発工程の半分以上は
プレゼンテーションに費やされますよね。
#実際には2/3以上だと思います。

JavaScripでの細かい制御はJSFで、ある程度できますが、
画面設計に無理がないかは検証したほうがいいです。
どのJSF実装のバージョンがいくつかは、
早めに決める事になるでしょう。

あとは、意外と忘れ去られているのがセッション管理
invalidateで全消去で済むのかどうか、
入念にチェックする必要があります。

もし、これがすまないとなると、どのタイミングで
HttpSessionから対象のオブジェクトを消さないといけないか、
決め、その決定に従って、実装する必要があります。

このときの私のお勧めが、状態遷移表を作成する事です。

状態遷移表で、オブジェクトのライフサイクルを定義すると、
消去漏れが置きにくくなります。

と、言っても状態遷移表は慣れが必要ですが…、

[12] mixiユーザー 04月16日 10:15

Struts自体が枯れてきて(悪くいうと、萎れてしおれかけていて)、お客さんの要求するプレゼンテーション層を実現できなくなってきているとおもいます。
お客さんがシステムと向き合うのはプレゼンテーション層なので、このあたりの設計がシステムの評価に大きく影響してきますよね。
ですので、ひでおさんのお客さんのような要求は今後、どんどん出てくるのかなあと思います・・・・。
現時点では、DI＋リッチクライアントってことでしたら、S2＋S2JSFまたはS2 + S2Flexがよいかも・・。
S2JSFはJSF自体の開発手法なり開発環境なりの動きがもう少し固まってからのほうがいいような気がしています。
また、S2FlexはJavaBeansとActionScriptのマッピングをしてくれるので便利です。あと、S2Container上に登録しておいた OR 自動的にされているコンポーネントのメソッドをFlex側から呼び出せるようになります。ただし、ボクがプロジェクトで評価したときには、Flex側の ActionScriptまわりの動きに不具合が、すこしばかり残っていたような記憶があります。現状、どうか知りませんが・・。
その点、リッチクライアントへの対応は、枯れたテクノロジーを組み合わせたAjaxが現実的なのかもしれません。でも、Ajaxは複合技ってことで、あるていど幅広い経験をもったデベロッパでないと対応がむづかしいという面がありますよね。ですので、プロジェクトで即採用ってのがなかなか判断がむづかしいです・・。
ほんと、ビジネスロジック層のコンポーネントまわりの生産性や保守性がDIで解決されつつあるので、プレゼンテーション層まわりもなんとかならないかなとおもっています。
その点、RoR(Ruby On Rails)はうまく現実解を見せてくれてるような気がします。
でも、お客さんは依然として、J2EE(Java) OR .Net(C#)っておっしゃるので、なかなかプロジェクトで採用できないんですよね。

[13] mixiユーザー 04月16日 18:48

JSFを実用化できるのはいいなぁ。
うちはStrutsの既存資産を生かしておきたいらしくて、JSFはStruts2系がでるまでは難しそうですよ。

みなさんプレゼン層はどんな感じなのでしょう？

[14] mixiユーザー 04月17日 06:55

>Wedgさん
僕はプレゼンテーション層としては「mayaa」や「Wicket」に注目しています。
特に「mayaa」はStrutsとの連携も容易なので今度のプロジェクトでは採用してみようかな、と思っています。

[15] mixiユーザー 04月17日 10:22

＞tekuさん
DIで保守性や生産性を解決できると言うのは同意見です。
但しそこにもルール化が必要で、ルールからかけ離れた作り
をされてしまうと、品質が劣悪となり、保守に工数がかかって
しまう危険性がありますね。
その辺の縛りをどのようにして実現するのか、未だ見つかって
いません。さしあたっては、抽象クラスを継承して実装し、
さらに、公開されるメソッド群用のコードテンプレートを用意
して、だれが書いても似たようなコードとなるようにする工夫
はしてます。

リッチクライアントの件ですが、私のプロジェクトでは、Biz
Browserを使用しております。この辺は、httpを使用したクラ
サバ開発の様になりますね。
後はクライアントとサーバのやり取りにおいて、リクエストパ
ラメータの持たせ方とかを取り決めする必要性が出てくるとい
ったところでしょうか？

次回は、DIを目指していた頃のサーバ側クラス図を掲載します。
これをみんなでたたいて、このコミュニティでのアーキテクトを
みんなで作りませんか？

ご意見おまちしてます。^^

[16] mixiユーザー 04月17日 11:23

なんか細かいところばかりつついて申し訳ないのですが（笑）。

jack_spallawさん:
> 抽象クラスを継承して実装し、

というのは、どんな感じでしょうか？

DIコンテナというと、従来のEJBコンテナで取られていた「継承による機能実装へのアンチテーゼ」という印象が強くて、継承を使わないほうがいいのかなと感じていました。

僕のチームでは特にルールのようなものは設けず、単純に全体設計をする時点でのUI側からの呼び出し口、Facadeというか、今風にいうならサービスですが、ここのAPIだけが合意されていれば、内部の作りはエンジニアの個性に任せてしまっています。

ただ、おっしゃる通り何らかのルールがないと危険なので、継承を使ってコントロールが実現できるなら良い気もします。

可能であれば、コードか機能を教えていただけるとうれしいです。

[17] mixiユーザー 04月17日 11:42

＞松尾さん

mayaaはおもしろそうですね

うちはクライアントに画面見せるためにHTMLを先に作っているので、うまくいけばそのまま使えそうですね。

暇な時間作って遊んでみます。

[18] mixiユーザー 04月17日 13:42

やっぱりみんな似たようなこと考えるんですね。

私もwebフレームワーク作ってます。
http://sourceforge.jp/projects/feat/

mayaaとWicketの中間みたいな感じですね。メッセージとかボタンとかにいちいちコンポーネントを定義するとか、ほとんどXMLでプログラムを書いているようなものはどうも受け入れがたかったので、原始的に作ってます。

コンセプトは
・ピュアなHTMLのテンプレート
・設定ファイルは極力簡素に
・Javaで書けるものはJavaで書く
・タイポ地獄をなくすためにできるだけコンパイラと設定ファイルのバリデーションでチェックさせる
・意識しなくても再利用可能なコードが書けるようにする
という感じです。

最初はtapestryとStrusの中間のつもりで作っていたんですが(タペラッツて呼んでました)、結局DIを採用してしまいました。流されてるなあ、俺。

[19] mixiユーザー 04月18日 15:10

まずは初心に立ち戻りたかったので、
私のプロジェクトメンバーと作成した、クラス図を
貼り付けます。
私たちの出発点はここからでした。
judoにて作成してます。
プロジェクトファイルをご希望する方、MIXIのメッセージにて
ご一報ください。

[20] mixiユーザー 04月19日 14:13

昨日提示させていただいたクラス図について
抽象クラスが３つほど現れていますが、
業務基幹系システムの場合は、そのほとんどの処理に
おいて、定型的な処理が存在します。
それら定型化された処理を、抽象クラスのメソッド群に
全て押し込めてしまい、似たようなコードは業務AP開発
者に書かなくても良いような配慮をしました。
又、それらメソッド群の呼出順序については、コードテ
ンプレートに記述し、開発段階では、コードテンプレート
を使用するよう義務付けました。
此れを発展させて、更に、サービスへロジックのオブジェ
クトを注入できるようにすることを考えました。

ログインすると、みんなのコメントがもっと見れるよ