続々Teedaのメリット・デメリット
id:habuakihiroさんのところで、かなり腑に落ちた感じです。
要するに「いいじゃん、これで」って思えるほどほど感がほしいんですね。 足りないくらいがちょうどいい。あとは自分たちの都合でどうにかするから。 最初から考え抜いた仕様ってのは、現場では無理があるわけで。 ひとつずつのプロダクトはちょっと足りないくらいでよくて、 それが出来るだけ個別にバラバラであるほうが部品としてのレバレッジが利く。 変にスタックを意識されていると困る。それはスタックスィートを否定してるんではなくて、 部品の観点とは別に進められるべきだということです。 JSFやEJBは部品としてはでかすぎるのでレバレッジが利かない。
個々のプロダクトを小さくシンプルに保つという意味では、
この点はとても重要ですね。またスタックと部品の観点はそれでよいのだというの納得感があります。
「スタックとして優れること」と、「部品として優れること」、は
提供形態も異なるし、訴えたいポイントも異なってくるだろうから、
そこは分割すべきという点は同意です。
また、実際JSFという実装を作ってみた感想を付け加えると、JSFは仕様が複雑です。間違いない。
部品としてレバレッジを効かすには仕様が大きすぎる感は否めないです。
賛否両論ありますが、Servlet仕様くらいの小さな仕様で良いんじゃないかというのが個人的な結論。
JSFは大風呂敷すぎるんですよね。Webに絞り込んだわけではないという記述があったり、
携帯対応やその他HTTPに依存しないようにとかなり広範囲にサポートしなくてはいけないあたりがかなり悩ましい。
BeansあればS2Dxoイラネっていうなら、だったらコンテナに入っていてほしくないわけです。 逆にS2Dao使ってれば新しいS2JDBCなんていらんのでコンテナに入っていてほしくない。 コンテナそのもののメンテナンスでバージョンが上がるのか、 DxoやJDBCなどのために上がるのかという切り分けが出来ない。 使ってない部分のためにバージョンをあげるのはリスクです。 部品としてのレバレッジが弱いというのはそういうことです。
これにも同意かな。
少なくとも部品のレバレッジ効かすって観点は重要だとは思う。
部品を組み合わせるメリット・デメリットと、あらかじめパッケージングして
配布するメリット・デメリットのバランスについてのひがさんと羽生さんの意見の相違だとは思いますけどね。
全部パッケージングして配るというのには、S2.4を使っているならS2JDBCを使ってよという明確な意図があるとは思う。
逆に全部部品ばらばらでそれを組み立てる初期コストがあまりに大きいのであれば、
そこはパッケージで提供して欲しいと思うだろうし。
