2009年10月アーカイブ

MVCのModelをWAFから切り離しつつ、Modelも（DBとの仲立ちをさせる）ORM用スキーマと（ビジネスロジックを書く）ドメインモデルとで分けたいと思い、ここ数日調査や試行をしています。私はPoEAAを読んで、かっとなって「どうせ趣味で書くならドメインモデルしかない！」と思い込んでいます。これがまず出発点です。今回の記事は、そのモデルの守備範囲をどうしようか、というお話です。

まず、CatalystなどのWAFからMVCのMを切り離すことについては、牧さん(lestrratさん)の『モダンPerl入門』(pp.116-121)などで明快に解説されています。

次に、サービスクラスとモデルクラスの使い分けについても、dannさんのCatalystCon #1でのCatalystからModelを切り離せ - MVCのMのあるべき姿 -の発表でも言及があります。

それでは、ドメインモデルはDAO/DTOやORMの方面まで面倒を見るべきなのでしょうか。

今回細々と開発しているFF14ユーザー向けウェブサービスであるAmikecoでは、ORMとしてDBIx::Classの使用を想定しています。また、サービスクラスやモデルクラスは、Mooseクラスを想定しています。

というような状態での具体的な実装方法について、調べてみたところいくつかの類型があるので、試行してみての感想を添えて備忘録として書いておきます。

1. MooseクラスでDBIx::Classを継承して、ドメインモデルにスキーマを兼務させる
2. DBICx::Modelerを使って、スキーマクラスとモデルのMooseクラスを分離する
3. MooseX::DBICを使う
4. 永続化非対象の情報をどう持つか
5. 番外編: Moosified ORMを使う
6. まとめ

前の記事の論旨が微妙に（かなり？）飛躍していることに気付いたので補足しておきます。

まず、DIパターンやDIコンテナーを使うことの目的は、直接的には、モジュール間（より具体的には、例えばドメインモデルとORMというようなレイヤー間）の結合性を疎にすることです。

「Mooseのアトリビュートへ依存オブジェクトを持たせることでも疎結合に出来る」というdannさんの指摘（DIとは何か 番外編 - DIコンテナを使わずにModelのTestabilityを高める方法）が一つの具体例ですが、元々Perlは（動的言語であるので）イントロスペクション（オブジェクトの中身を実行時に参照すること）のみならず実行時のDI自体はお手の物です。従って、DIがなければ死にそうなくらい大変かというと、必ずしもその通りではありません。

ただ、あまり根を詰めずとも試験容易性（テスタビリティー）の向上という利益が得られるという点で、DIコンテナーのお世話になる費用対効果が大きいと判断しました。私は怠け者なのです。

さらに、DI採用によって将来的に（今回は使用を一旦留保した）新進気鋭のモジュールに切り替え易くするという狙いもあります。これは「新進気鋭のモジュールを活用する実装を一旦断念して、定番のモジュールを活用することにした」という自分自身の負い目に対する代償行動のようですが、これこそが今回DIコンテナーのお世話になることに決めた最大の理由だと自己分析しています。

ということで、何故突然DIコンテナーを実用してみようかと思ったのか、その辺りの事情についての補足でした。前段と後段の内容の結節点となるこの補足がないと、何が何だか分かりませんでしたね。補足があっても寝不足気味なので変なことを書いているおそれがありますが。

ここのところPerl勉強日誌的な記事が続いていますが、ff14.nameとff14.asiaの開発は細々と続いています。それはもう申し訳ないほどに細々としていますが......（一方で、「やや真面目なサイト」としてサイドバーに晒してあるエスペラント日本語翻訳システムは、かなり遅滞気味です）。

これらサービスのそもそもの開発動機の一つが自分自身の勉強ということもあって、色々と新進気鋭のモジュールを試しながら使わせていただこうとして出発点を置きましたが、少なからぬ依存モジュールの数々を、新進気鋭のモジュールではなく、定番系のモジュールに切り替えようとしています。これは、定番系の重厚長大モジュールでさえ深く使い込んでないのに、新進気鋭の軽薄短小なモジュールを巧く使いこなせずに開発が遅滞するということが、早すぎる最適化の一類型に当てはまるのではないか、という危惧に由来するものです。最終決定はまだ先ですが、10月20日版の主要依存(予定)モジュールなどでは、その辺りの弱気が透けて見えるかも知れません（「or」の前後をかなり入れ替えています）。

具体的には、例えば

• やっぱりまだまだRDB的な考えからKVS的な考えに切り替えが出来ない私は、Data::Modelではなく、まずはDBIx::Classで一通りを組んでみようと考えを改めました
• 出来るだけAny::Moose経由でMouseを使うようにしていたのですが、まずはMooseの豊富な拡張モジュール（MooseX::*）にお世話になってプロトタイピングにいそしもうとしました

などという点です。

この方針の転換は、すべて私の能力の至らなさによるものです。8月中旬頃まで色々試行錯誤をしていたのですが、色々な使いどころの妙を得ずに開発をしていて、プロトタイピング自体で蹴躓くことが多かったという体験があります。ということで、最初から完成形のアプリケーションを作れるわけでは当然ないにせよ、まずは形を作ってからそれから新進気鋭のモジュールの使用を試みようというような、私の身の丈にあった開発をしようと思います。モジュールそれ自体が冒険的ということでは全くなくて、モジュールを自分が十全に使いこなせないという冒険的な開発を改め、多少なりとも安定的にプロトタイプを作れることを優先するということで。

などと書いた舌の根も乾かぬうちにというか打鍵音も静まらぬうちに......。

Mooseのアトリビュートには、多くのオプションがあります。これらはハッシュとして渡すので、順不同で指定することが出来ます。

この指定順について、私はこれまで結構場当たり的に決めていました。軸足となるのはやはりMoose::ManualやMoose::Cookbookの例になりますが、一旦整理してオレオレルールというかオレオレガイドラインを考えてみようと思いました。

あまりにも毎回ばらばらだとコードが明快でなくなりますし、その逆で並び順次第でコードがより分かりやすくなるなら、やっておいて損はないものだと思います。

とはいってもこれはあくまでネタなので、どうか真に受けないようにしてください。

それでは、Moose 0.92時点でのオプション指定順私案をご紹介します。

1. metaclass
2. traits
3. is
4. accessor
5. reader
6. writer
7. isa
8. does
9. coerce
10. weak_ref
11. auto_deref
12. init_arg
13. required
14. lazy
15. lazy_build
16. predicate
17. clearer
18. default
19. builder
20. trigger
21. handles
22. documentation

これらの並び順の意図などは、以下で補足しています。

Mooseのtriggerの効果的な使い方について、遅ればせながら先のMoose入門研修で始めて知りました。簡単なサンプルコードスニペットも用意出来たので、まとめておきます。

この記事の対象読者としては、私と同じMoose初心者の方々を想定しています。

1. そもそもtriggerとは何か
2. 具体的な使いどころ
3. もしtriggerがなければ......
4. lazyした導出先のアトリビュートをclearすべき
5. 具体例の数々（サンプルコードスニペット付き）
6. まとめらしくないまとめ

10月8日の深夜に前の記事へ追記をしたのですが、一応念のため新しい記事でもご連絡しておきます。Moose入門研修(Introduction to Moose)のスライドに続いて、演習問題(/moose-class/exercises/t/*.t)の日本語訳も行いました。

で、後は私のバージョン管理にかかる備忘録というか反省文です。

Moose入門研修(Introduction to Moose)のスライドを日本語訳してみました。

演習問題（未訳）を含む日本語版の一式はGitHubのリポジトリに置いています。興味のある方は、git clone git://github.com/gardejo/moose-presentations.gitするなどして入手してみてください。

石垣さん(charsbarさん)のとてもわかりやすいMooseドキュメント日本語訳には及びもつかない翻訳ですが、用語の訳語を適宜剽窃しつつ、今回は取り敢えず粗訳・試訳からの出発ということで一発japaneseブランチを切ってみました。

原書はDavid Rolskyさん(DROLSKY)さんによる力作です。git clone git://git.moose.perl.org/moose-presentations.gitで入手出来ます。CC-BY-SA 3.0でライセンスされていますので、日本語版という派生物を今回公開させていただきました。日本語版のライセンスも、原書を継承してCC-BY-SA 3.0です。

補足事項や所感などを以下に簡単に述べます。

どうしてこんな辺鄙なサイトに目を付けたのか皆目不明なのですが、広告掲載依頼のメールをいただきました。

ということでその返信メールは以下の通り（メールは信書だと考えているので、先方からいただいたメールや、先方の名宛ては公開していません）。

●●　御中

ff14.name, ff14.asia, eorzea.asiaの各サイトを運営しております●●と申します。 この度は広告掲載のご連絡をくださり、どうもありがとうございました。

折角お誘いをくださったのに恐れ入りますが、現段階での広告掲載はご遠慮させてください。ご期待に添えず、大変申し訳ございません。

当サイトは特定分野（オンラインゲーム）のユーザー向けウェブシステムを開発する目的で開設しております。しかし現段階では当該システムは未完成であり、広告主様の期待するPR効果をお約束致しかねると判断致しましたためです。 貴社のユニークな形態での広告はとても興味深いものであり、当サイトのシステムが完成して広告掲載を検討させていただく際には、貴社サービスも検討させていただきます。

以上よろしくお願い申し上げます。

--

●●（署名省略）

有用なサイトが運営費に苦しんでしまうのは残念なのですが、さりとて手段と目的をはき違えて、内容がなおざりな状態で広告ばかり貼り付けてしまうようなサイトは私は苦手です。仮に当サイトが現段階で広告を貼り付けたとすると、後者の例に当てはまることは明白です。

運営情報のページで、将来的な広告掲載等を検討していることを明示していますが、流石に現段階では早すぎますよね。

ただ、ラジオ広告をウェブ広告が追い抜いた話などもあって、こんな辺鄙なサイトにもその余波が及んだのかと、感慨にふけりました。