ラッパ型のフレームワークの場合どこまでいじるべきか

Springは例えばStrutsとの連携はわりとゆるく、Strutsの昨日をほとんど隠していない。便利な機能をつけるだけ。

メジャーなフレームワークの場合、開発環境やテスト環境等がそろっていることが多い。分厚いラッパのフレームワークだと大量の機能追加や本来の機能の隠匿でどんなに開発が便利になるとしても、それは開発をサポートする環境を失っても開発効率が上回るだろうか？

IDEのサポートがないただのテキストエディタで開発するのを想定して、JavaはLLより開発しにくいとアピールしてるのとなんら変わらないかなと思った。

ICEfacesはあれだけすばらしいコンポーネント指向のフレームワークだが、ロジック部分はJSFを使うという割り切り方のバランスがすばらしい。あそこまでやってしまったら、普通はプロセス部分等まで自分で実装してしまいそうになると思うのだが、この辺の切り貼りのバランスがSpringにしてもJBOSSにしてもわりとうまい感じがする。

つまり、隠匿度はユーザーにゆだねるというタイプかな。基本は用意しとくからあとは使うプロジェクトで好きなように拡張しろという感じで。たぶん、海外はこういうのが好かれるんだろうね。すでにあるものは使う。

StrutsでいえばRequestProcessorで軽い使い方を用意しておくといった程度かな。これを参考に後はご自由にという感じの適度な突き放しというか。

そういやGuiceはStruts 2との連携は用意してあるけど、Struts 1との連携は用意されてないね。日本だとStrutsといえば1ばかりで2の情報が少なすぎるのと比べてあちらではStruts 2はわりと使われてるのかな。JSFも結構使われてるようだし、日本とはかなり状況が異なるみたいだね。でも、先に海外で普及したものが日本でも普及してきたことを考えると日本でも状況は少しずつ変わる…と思いたい。

ちなみにGuiceだとRequestProcessorはこんな感じ。

public class GuiceRequestProcessor extends TilesRequestProcessor{

    @Override
    protected Action processActionCreate(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping) 
            throws IOException {
        try {
            Logger.getLogger(GuiceRequestProcessor.class.getName()).fine("action取得:"+mapping.getType());

            Action action = (Action) SingletonInjector.getInjector().getInstance(Class.forName(mapping.getType()));
            return action;
        } catch (Exception ex) {
            Logger.getLogger(GuiceRequestProcessor.class.getName()).log(Level.SEVERE, null, ex);
            response.sendError(
                HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
                getInternal().getMessage("actionCreate", mapping.getPath()));
            return null;
        }
    }

}

使うアクションはこんな感じ。

public class TestAction extends org.apache.struts.action.Action {
    
    private final static String SUCCESS = "success";

    @Inject
    private ItemService service;

    @Override
    public ActionForward execute(ActionMapping mapping, ActionForm form,
            HttpServletRequest request, HttpServletResponse response)
            throws Exception {

        request.setAttribute("items", service.getItems());

        return mapping.findForward(SUCCESS);
    }
}

実際この程度で十分な場合は多いし、これだけだとほぼStrutsの知識だけで開発できるし、ツールももちろんサポートしてくれる。後は慣れながら徐々に機能を増やしていけばそれでいいかなぁと。あまりにいたせりつくせりだと覚えることが多すぎて、ベースのフレームワークを理解しているだけだと開発が容易にできないこととか多くなるような気がする。メジャーフレームワークであることのメリットが薄れるんだよなぁ。

徐々に増やすというのがポイントで、効率は次第によくなるはず。なのだが、それだけにタコ部屋派遣労働型だと毎回人員がプロジェクトごとに変わるために知識がリセットされて効率向上は望めない。結果同じ構造で開発する場合においてもコストが一銭も下がらないという不思議な状態になる。

ああ、結局フレームワークやライブラリの優劣より開発体制のほうが一番重要だなぁというオチか。なんとかならんのかな。10年前よりどう考えても悪化してるのこの業界くらいじゃね?orz