t100のプログラミング脱出作戦

自分のプログラミング脳をプログラムにして、いつかプログラミングから脱出してやるぞっ!とか夢見ながら、日々プログラム作っていく 百野 貴博 の日記です!今は、屋号『百蔵。』として、Silverlight・WPFを追跡中です! (2007/09/30)
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
【--/--/-- --:--】 | スポンサー広告 | トラックバック(-) | コメント(-) top↑
次の記事はこれかな(謎の予告)
そんなこんなで、今日は久々に自社でJavaアプリ作ってました。
それにしても、気がつくとJava界は DI/AOP+O/Rマッパー 当たり前の世界に
なってたんだけども、自社フレームワーク時代が長かった自分が
転職を機に、突然そんなところに放り込まれても、なんだか全然ついていけない今日この頃です。

で、.netと比較してみた、Javaの開発がどうも重く見える原因と、自分なりに思う対策を書いてみようかと思ったんですが
今日はもうすっかり遅くなってしまったので、今後に向けた触りだけ・・・。
明日は、VSUGだしな~。早く寝ないと。

http://vsug.jp/tabid/171/Default.aspx

●Javaの開発で引っかかっている点

・DI/AOPを使ったトランザクション制御は、どうもイケテナイ臭がする。
View層とService層の間に、ゴニョっと入れ込む便利さは分かるんだけども、、、
「Spring 2.0入門」で紹介されていた遅延ロード問題なんかを見てしまうと、、、

・Java界は「依存」に対してチョット過剰反応なのでは。
そのせいで修正範囲が分かりにくかったり、コーディング量が無駄に増えたり。
インターフェイスをひたすら書いたり、値の受け渡しだけのコードが必要になったり。

・O/Rマッパーは、開発を楽にしてない気が。
DBに依存しない設計とかのせいで謎の複雑さ。
でもDB変更は接続文字列の変更だけでイケルなんて客も自分も信じてないぞ。

●ヒントになりそうだと思っている点

・ADO.NET 2.0の割り切った設計思想
なんていうか、インターフェイスで実装を隠そうとしてない点。一瞬目を疑った。

・LINQ
SQLをタイプセーフにできそうな勢い。
Javaに欲しいのは、DBの差分を吸収する超難解なORマッパーではなく
DBの変更点をコンパイルエラーに出来る仕組み。

・Groovy
SQLをコンパイルエラーに、、、と考えると
Javaにメソッドポインタが無いのが痛いなぁ。とか思ってしまう。
リフレクションは実行時の判断だからなー。
それだと遅くて、Eclipseとかのエディタでエラーを出したいですよね。

で調べたら、Groovyあたりで何か出来そうかも?

●メソッドポインタ
http://www.swlab.it.okayama-u.ac.jp/man/jdk-docs-ja/guide/innerclasses/spec/innerclasses.doc3.html
http://programamemo2.blogspot.com/2007/08/groovy-println.html

そんなことを考えていた金曜の午後でした。

まとまってないですが、、、

そんなわけで、Wicket + POJO + Groovy だけのシンプル構成で3層アプリを作れないか検討してみたいと思っています。

シンプルでサクサク開発の勝ちパターンを手に入れたいな。












管理者にだけ表示を許可する


トラックバックURL:
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。