DIコンテナから再勉強中
前書き
あんまりまともに勉強してなかったからね。
ということでSpringから入る。
http://www.atmarkit.co.jp/fjava/rensai3/springdi01/springdi01_1.html
http://www.atmarkit.co.jp/fjava/rensai3/jaee5mgrtn01/jaee5mgrtn01_1.html
今更だが、@ITの記事量はハンパじゃないな。
しかし下のは・・、ウプッ、お腹いっぱい。何このJxxの山。
まあいい、JAVAを学ぶということはJAVAコミュニティの歴史を学ぶということであり、Jxxやフレームワークやらツールやらを知っていて、使っていて、学んでいて、それら全てを「当然」と考える文化の土壌に上がるという事でもある。
出来る限り避けようと思っていたが、やむを得まい。JAVAを主要技術の一つに据えたのは、他ならぬ私自身であるのだから。
そんでなんだっけ、いいところ。
XMLでプログラムが書けるって事だっけ？
独自仕様のXMLを理解する方が、共通仕様のJAVAで書かれたプログラムを理解するよりしんどいと思うんだけど・・。
おっと、いかんいかん、またJAVA嫌いが顔を出してきたぞ。まともにやろう。
POJO
とりあえず、アンチEJB(2.x）から生み出されたこのPOJOが一つのポイント。JSFが持てはやされる理由もここだそうな。
で、POJOというのは、下記に詳しいが、
http://www.hitachi-sk.co.jp/research/techdoc/DI/
http://ja.wikipedia.org/wiki/Plain_Old_Java_Object
ただのクラス（オブジェクトじゃねーの？）であり、POJIというのはただのインターフェースだそうな。
要するに何のインターフェースも実装していないクラスに存在意義が無いような風潮に対して、いい名前をつければそれはいいもんだと理解されるだろうということで名付けられたものらしい。
じゃあJavaBeansってPOJOじゃないんじゃない？と言うと、JavaBeansはWikiPediaによると「厳格な命名規約を持つシリアライズ可能なPOJOであるとほぼ言える」だそうな。
ほぼ、て。おもろいな百科事典。
じゃあ「java.io.Serializable」は対象じゃないのかという気もするが、つまり、POJOというのはバズワードであり、EJBとJavaBeansが混同されがちになってきたのでつけられた、JavaBeansの別名であると考えればわかりやすい。
間違っている可能性もありそうだが、とりあえずその程度の理解に留めておく。
現時点での解釈：POJO = JavaBeansまたはJavaBeansの要件を満たしていない、JavaBeansみたいな使い方をされるもの。
JSFのDIコンテナ
http://www.hitachi-sk.co.jp/research/techdoc/DI/jsf.html
この辺に書いてある（ついでにJSFでSpringをDIコンテナとして使う方法も書いてある）が、JSF自体は既にDIコンテナを内蔵している。
で、通常JSFに管理させるならmanaged-beanに全部書かなきゃいけないのを、variable-resolverってのを書けばSpring管理下にあるBeanも管理することが出来るらしい。
で、その何が良いのかっていうのはこちらのBlogで書かれている例を参考にすると、
http://d.hatena.ne.jp/Syunpei/20061109
JSFの貧弱なコンテナ機能ではなく、最高に機能が豊富なSpringコンテナ機能を利用できると言うことです。
AOP、初期化メソッドの指定、@Requireアノテーション(v2から)、autowire、などなど・・・
さようでございますか。
文脈を読むと、1.x系のSpringなら導入はしない、2.x系なら導入推奨、なぜならSpringの方がDIコンテナとして優れているから、ということかな。
現時点での解釈：JSFにDIコンテナの機能は内蔵されているが、Springに比べれば機能が貧弱。Spring2.x以上なら導入検討の価値あり。導入するとJSF管理下Bean + Spring管理下のBeanを使用する、という形になる。
※不明点：逆にPicoContainer等の単純かつ軽量なコンテナは導入価値無しという事かな？
Springについて
さっきも貼ったがここが詳しい。
http://www.atmarkit.co.jp/fjava/rensai3/springdi01/springdi01_1.html
いわく。
こんなところか。
AOPについては、こんな例見せられてもきつい。
http://www.atmarkit.co.jp/fjava/rensai3/springdi03/springdi03_2.html
たった三行の出力のためにそれですか、と。そりゃMyMethodIntercepterは再利用可能でしょう。regexpAdvisorも再利用可能でしょう。
でも、これならAspectJ使うべきじゃないか。
http://www.atmarkit.co.jp/farc/rensai/aspect02/aspect02a.html
機能拡張じゃなくて初期から構築するプロジェクトだとして、メソッドのin, outのロギング程度なら、少なくとも使うメリットは感じないな。ログ好きに怒られるかもしれないが、たかがロギング程度にそれほどの工数をかけたら駄目だろ。
この記事もそれ程新しくないから、今はアノテーション使ったシンプルなやり方をサポートしてんじゃないかなぁと思われる。予想。
おわりに（蛇足）
とりあえずメモ書き程度にまとめておいた。
だからXMLはコンパイルすら出来ない劣悪なプログラミング言語なんだっつーの、と言いつつ、まあJAVA界へのリハビリ程度にゃ丁度いいテーマだったな。
だからXMLの仕様はシンプルだろうがシンプルじゃなかろうが、いちいちファイルごとに仕様が違うから調べんの面倒くせーんだっつーの、と言いつつ、まあ仕方ないから理解しようじゃないか・・。
次はO/Rマッパーだな。ちょっと前からHibernateの名前を聞きすぎる
Hibernateも下手に使うとパフォーマンス低下を招くだけな気もするのだが、ちと知識が足らなくて結局Section2がHibernateを使用することを止める事も出来なかったし。
軽く勉強しとくとしよう。
