ドメインモデルって不要なんじゃない？って話があってビックリしました。僕はてっきり（リッチな）ドメインモデルは不要っていう理解をして、そうだよなあと思ったのですが、そうじゃないんです。
StrutsベースだとActionFormがStringベースとなるから、詰め替えするコードが必要になる。だからテーブルと1対1になるようなエンティティって感じのクラスがあっても変に思わないけど、JSFなら型が決まるから詰め替えなくてもいいんじゃない？ってこと。さらに、ユーザさんと話すときはテーブルじゃなくて画面を元に話すでしょ？って言われてあ〜〜っと思いました。画面に近いところで定義する方が変更に強いのかも。
リプレースのシステム開発だとやっぱりテーブル構造を帰ることが難しい場合が多くて、エンティティを作るとフィールドがやたら多いクラスとかできて個人的には困ります。画面からのデータをそのまま適切なテーブルに振り分けて入れてもらえるような仕組みだとどうなるんだろう？楽だなあって思う。問題出てくるかな。。。？
データアクセスの話にそのまま流れて、Hibernate使ったときにすごく感じたけどこうしたいびつなテーブル構造のときには対応できない。。。ひがさんとしてはそれは切り捨てるんじゃなくて救っていきたいとおっしゃってました。データアクセスで複雑なSQLになるのは結局3割程度だから、大部分は無設定で使えて、例外的なものには自分でSQL書いてきちんと対応できるっていうのはやっぱり素敵だと思う。
ロッドは(Springは)設定を明示的にしたいから、これからも設定ファイルは書くし、Seasarは書かない方向に進んでいる。同じDIコンテナでもいろんなプロダクトがあるのが健全だよっておっしゃってました。Spring×Seasarってすぐになるけど、個人的にはSpring + Seasar ( + EJB3 )って感じでいろんな現場にDIが広まってほしいと思ってます。SeasarはSpringにはないものがたくさんあって、ぜひ世界でDIコンテナの双璧になってほしいです。
（さらに続き）大阪Javaコミュ準備会＋wakhok夜学行ってきました！
