URLMappingの持ち方の設計について

pythonではもうURLMappingの書き方が2つぐらいしかなくて

1. URLMappingを書いた専用のモジュールを使う
2. decoratorでMapping

って方法があるんだけど使い分けの方法としてどーするこーするってのがある。

URLMappingを書いた専用のモジュールを使う

この方法の利点は以下。

1. どのURLでどの関数が呼ばれるか一目でわかる
2. URLMappingをコードから生成できる

どのURLでどの関数がよばれるかすぐわかるってのはそんなの重要じゃない。
もうパターンとしてview、もしくはviews.pyあたりにそれっぽい名前でMappingするのでviewのコードを見ても推測がつく。

やはりURLMappingをコードで作れるってところが大きい利点になる。
例：

    tmp = '/'
    for digits, part in zip(app.cfg['fixed_url_date_digits'] and (4, 2, 2)
                            or (0, 0, 0), ('year', 'month', 'day')):
        tmp += '<int(fixed_digits=%d):%s>/' % (digits, part)
        blog_urls.extend([
            Rule(tmp, defaults={'page': 1}, endpoint='blog/archive'),
            Rule(tmp + 'page/<int:page>', endpoint='blog/archive'),
            Rule(tmp + 'feed.atom', endpoint='blog/atom_feed')
        ])

werkzeugのRuleTemplateようなパターンもこっちの方法じゃないと書けない。
似たようなURLを多く扱うような大規模な開発にはこっちの方があってる。

decoratorでMapping

この方法の利点は以下。

1. ファイルがひとつ減る
2. Mappingミスが防げる。

イチイチ編集するファイルを切り替えるアホ臭い作業から解放される。
（これは意外に大きくサクサク感が違う）
大概、アプリケーション単位でviewはまとめるので、どのURLでどの関数が呼ばれるかはviewのコードみれば別にわかる。
viewコードを書き、そのままdecroatorでmappingするのでmappingし忘れとかほぼ無くなる。
但し、このパターンを使う際には別途サブアプリケーションごとのdispatcherなどのsubmount系を補う仕組みが必要になる。

悪い例

main/view.py

@expose('/')
def index(req):
    .....
    return Response()

......

admin/view.py

@expose('/admin/')
def index(req):
    .....
    return Response()

......

mainのアプリはいいけどadminアプリにわざわざ/admin/と書くのがだるいし、URLMappingが固定になって自由度が減る。
なのでwerkzeugのDispatcherMiddlewear、Pasteのurlmapみたいな仕組みで補う。
小さい規模ではこっちで十分。

あと僕個人としてはpythonでは関数がファーストラスオブジェクトなのでControllerクラスなんて絶対に要らないと思ってるのだが利点があるって人は教えて下さい。
（pythonはOOを強要しない。状態をもたないクラスは必要ない）