Guice＋Struts

StrutsとGuiceを連携させて、struts-configを一切書かないようにしてみようと思った。

そのままだとつまらないので、Strutsの一番いやな部分を直す。具体的にはアクションフォームのキャストをなくしてみた。GuiceなんだからGenericsを使うだろJK。

そして出来るだけStrutsであることを隠さないつくりにする。ラッパが分厚いと本来のフレームワークに慣れた人もアレルギーを起こすかもしれない。

というわけで、面倒なconfigとキャストをなくして、DIコンテナで管理させてサービスとの連携を容易にした。それ以外はすべてStrutsの知識が使える。

以下アクションクラスのサンプルソース。

public class MessageAction extends TypeAction<MessageForm>{

    //コンテナのサービスもすぐに使用可能
    @Inject
    private MessageService service;

    @Override
    public String executeAction(ActionMapping mapping, MessageForm form,
            HttpServletRequest request, HttpServletResponse response) throws Exception {

        //アクションフォームのキャストは必要なし
        request.setAttribute("msg",  service.hello(form.getName()) );
        
        //通常のStrutsのメソッドももちろん使える
        ActionMessage am = new ActionMessage("message.error");
        ActionMessages ams = new ActionMessages();
        ams.add(ActionMessages.GLOBAL_MESSAGE , am);
        saveErrors(request.getSession(), ams);

//        return "/message.jsp";
        return "redirect:/messageAction2.do";
    }

}

どういうことになってるかすぐに分かってくれると思う。

• Guiceのコンポーネントがインジェクトが可能
• Genericsで型を指定するのはアクションフォーム
• アクションフォームはキャスト不要
• JSPのパスそのまま使う
• リダイレクトは「redirect:」をつける

まぁSpringMVCに影響を受けてはいるとは思う。

大本のフレームワークをどれだけ隠すかどうかは人によって大きく意見が分かれるところだと思うけど、個人的にはこれくらいが元のフレームワークを理解している人のアレルギーを起こさないぎりぎりの線かなと思った。後はフォーム周りの改善くらいかな、と。

無理にPOJOにしてActionのprotectedなメソッドを別パスでアクセスさせるとかだと使い方が大きく異なってしまう可能性もあるし。社内で整備したライブラリが手軽に使えないというのも出てくるかもしれない。