ＤＩコンテナについて考えるのバックアップ(No.6)

Eclipseについている JUnitはちょっと古くて、Springに対応するために必要なインターフェイスJUnit4ClassRunner?が存在していない。なので Eclipseに標準で付属している JUnitをビルドパスから外し、最新の JUnitへビルドパスを通す必要がある。その場合でも "Run as"→"JUnit TestCase?"はちゃんと動くので心配ない。

「spring-mock.jar」はSpring 2.5ではTestContext?フレームワークに焦点を絞った「spring-test.jar」に置き換えられました。しかし「spring-test.jar」には「spring-mock.jar」の内容がすべて含まれているので、既存の単体・結合テストで使用する場合でもそのまま置き換えることができます。

↑

参考URL †

http://walbrix.net/blog/2010/05/spring.html

↑

Seaser２の入門 †

http://snowhiro.web.fc2.com/seasar2/seasar2_index.html

Seaser２もブツブツインタフェースで区切って、

設定ファイルで関係付けしてといったぐあい

↑

s2Dao †

最大のメリットはＳＱＬの自動生成

↑

S2JDBCとActiveRecord?の比較 †

S2JDBCとRailsのActiveRecord?は、エンティティとテーブルは同一構造となる点は同様だが、細かいようで重要な違いとしてActiveRecord?は豊富なメタプログラミングを駆使してエンティティの操作に対して豊富なフックを用意しおり様々な介入を行えます、それらを利用してデータ格納先としてのEntityに限定されず比較的ロジックを内部に保持できます。 JPAではエンティティマネージャから返却されるインスタンスはプロキシ化やエンハンスを行いEntityライフサイクル内で限定的な介入を行えますが、一般的にはあまり使われていないようです。対するS2JDBCはエンティティを純粋なPOJOとして扱います。意図しない挙動をしないため解り易いなどメリットと柔軟性のトレードオフで一概にどちらが優れているとは言えません。Seasarシリーズには実用的で便利な2WaySQLがあったり言語特製もふまえ同列で比較出来ない差を感じます！

そういえばHibernateよりCayenneが使いやすいといった意見を見た事があるのを思い出しました。JPA対応とかしてたような気がするのですがJPAエンティティライフサイクルの問題とかHibernateに対する違いってどうなんでしょうね？

↑

何が省力になるのか †

単体テストがしやすくなる。

↑

何が不便になるのか †

Springの２．５までは下記の問題があった。

Javaの静的型チェックができなくなる
xmlの定義が面倒

でもSpring３．０からは改善されている模様。

ＤＩコンテナについて考える のバックアップ(No.6)

目次 †

DIコンテナについて †

大体の方針 †

名前の由来について思うこと †

Spring（本家 英語） †

ダウンロード †

SpringFramework?の導入 †

ビルドパスに追加 †

Springの入門 †

Spring での Object/XML マッピングのサポートを探る †

Spring Framework 3.0の新機能 Part1 †

Spring Framework 3.0の新機能 Part2 †

Spring Framework 3.0の新機能 Part3 †

spring-test.jar †

Eclipseについてる JUnitを捨てる †