フレームワーク選定で失敗

約1年前、小さなプロジェクトで、使用するフレームワークの検証選定などして、組み合わせを決定する立場になって、いろいろ考えたことがあります。

そのときは、struts + velecity + spring(JDBC抽象化フレームワーク含む)という構成に決めました。

あまり複雑でないほうがいいという頭ではいたんですが、自分が決める立場だとついつい、やりすぎちゃうんですよね。O/Rマッピングも検討したけど止めといた。


そのプロジェクトは結局結構(相当?)苦労しました;;フレームワーク構成についての資料と結構な規模のサンプルまで渡したのに、協力会社からは、「最近のjavaは難しいですねw」と皮肉めいたことを言われたし。

振り返ると、struts + velecity + DBUtils にしとけばよかったなと。

javaやったことある人なら、struts経験はあるだろうし、DBアクセスは、昔ながらのJDBCのやり方(PreparedStatement 用意して、…最後にclose()というやつ)は、知ってるから、DBUtilsは自然に使えるだろうし。


社内メンバや協力会社の経験値も踏まえた上で、みんなが無駄な苦労をしない方が良いし、新しいこともバランスよく業務に取り入れた方がいろいろな意味(モチベーションとか)でいいだろうし。


結論:フレームワーク構成を決める(立場に立つ)のは、大変なこった。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です


The reCAPTCHA verification period has expired. Please reload the page.

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください