Prana は(リンク) Adobe Flex や ActionScript 3 をつかった開発をサポートする、制御の反転（ IoC ）タイプのアプリケーションフレームワークだ。今回 InfoQ では、Prana フレームワークを開発した Christophe Herreman 氏と Damir Murat 氏に、フレームワークのつかい方について話を聞いた。
InfoQ: 整ったフレームワークはほかにもあるのに何故 Prana を開発したのか、InfoQ の読者に向けて説明をお願いしたい。
Herreman: Prana は、わたしたちが ActionScript 2 と Flash で開発された e ラーニングプラットフォームの書き直しを始めたときに生まれた。わたしたちが使っていたライブラリのひとつは、as2lib で使うことのできる IoC コンテナだった。これまで IoC を適用して非常によい結果が得られていたので、わたしたちは自分たちの新しいプラットフォームに同じ機能がほしいと考えた。その当時、 ActionScript 3 で使える IoC コンテナは存在しなかったので、わたしはそれを自分で作ろうと決めた。
わたしは、Spring でつかわれる XML 記述をベースにした独自の実装から出発してすぐに、可能な限り Spring のコードベースを基礎にして開発を進めることに決めた。Spring のソースコードは閲覧可能なので、その方法であれば、いくつかの機能がより簡単に実装できるだろうし、Spring に詳しい開発者ならすぐに Prana を使い始めることができるようになる。そしてもちろん Spring の内部のことを学ぶのは自分にとって楽しいことだった。
InfoQ: あなたが Prana フレームワークの独自性として考えているのは何か？
Herreman: Prana フレームワークは非常に汎用的で拡張性に富み、パワフルな IoC コンテナ(リンク)だ。もしあなたが Spring IoC コンテナのことをご存知なら、Prana に何ができるのかがよくわかるだろう。
ナイスな独自機能の一例としては、XML パーサに独自のプリプロセッサを追加できることが挙げられる。プリプロセッサを使うと、XML がロードされた後、パースされる前にその内容を変換することができる。ユーザは、自分にとって都合のよい方法で独自オブジェクトを記述するための要素や属性を追加し、それらの要素を Prana パーサが理解できる要素へと変換するための独自プリプロセッサを準備することができるわけだ。
IoC コンテナとしての機能に加えて、describeType() の上に構築されたリフレクション API もある。ユーザは、アプリケーション内に存在するオブジェクトの実行時情報にアクセスするための API を手にするのである。知ることのできる情報は、たとえばオブジェクトがどのようなプロパティやメソッドをもっているのか、どのインタフェースを実装しているのか、といったものだ。その一方でわたしたちはドメインオブジェクトのための基底クラスにも取り組んでいる（ Eric Evans 氏が書いたドメイン駆動設計本にインスパイアされた）。それら基底クラスにはオブジェクトを比較したりクローンしたりするためのロジックなどが含まれている。そして Prana にはおもしろいユーティリティクラスもある。
Murat: Prana を使ったプロジェクトを簡単にスタートするためのツールも準備されている。主な機能のひとつは、コード上は参照されていないクラスをコンパイル済みの swf に含めるよう Flex コンパイラの設定を動的に変更できるものだ。IoC システムは、クラスではなくインタフェースを使ったプログラミングを促進するので、この機能は頻繁に必要とされる。わたしたちのツールは Eclipse/Flex Builder と密接にむすびついており、たとえば Prana の設定がいつ変更されたかなどを検出することができるし、必要とあらば、Prana の設定ファイルを解析し、それに従って Flex コンパイラの設定を変更することも可能だ。これは、プログラマが、最終的なコンパイル済み swf にクラスを組み込むために、それらのクラスがコードから到達不可能であることを明示的に宣言しなければならない場合に、古典的な Flex のパターンの必要性を抑えてくれる。Prana が提供するツールはこれを自動的に行ってくれる。
事前定義されたプロジェクトレイアウトや Ant ターゲット、subversion でプロジェクトを共有するためのサポートなど、ほかにもいくつかの機能がある。どの機能も設定が可能で、段階的な手順にしたがって、簡単にデプロイを行うことができる。さらに詳しい情報に関心のある開発者は、svn またはフルディストリビューションアーカイブで、利用可能な Prana ツールを確認することができる。
InfoQ: Prana は Cairngorm と PureMVC の両方と統合されている。Prana が何故、そしてどうやってこれら二つのフレームワークと連携しているのか説明をお願いしたい
Herreman: Prana は Cairngorm と PureMVC 用に一連の拡張を準備している。IoC をつかっているので、使用しているフレームワークにその原則を適用し、依存性注入（ DI ）をつかっているアプリケーションの異なる部分同士をつなげることができるようにもしたい。
Cairngorm 用には、IoC コンテナで設定できるサービスロケータを提供する。ユーザは、リモートオブジェクトやチャネルセットやコンシューマなどを外部で定義し、アプリケーションを再コンパイルせずにそれらを変更することができる。このやりかたなら、services-config.xml ファイルに対してコンパイルをする必要もないし、異なる場所にデプロイするのも簡単だ。テストも簡単になる。典型的な使い方としては、開発用マシンからテスト用サーバや運用サーバへ移行する際にエンドポイントを変更したい場合がある。Prana ならアプリケーションのリビルドなしにこれを簡単に行える。
Prana が提供するフロントコントローラは Cairngorm フロントコントローラのサブクラスで、独自のコマンドファクトリが利用できる。そうすることで、どのようにコマンドが作成されて、その際にどのようにプロパティがインジェクトされるかを、ユーザがコントロールできるのである。それに加えて、あるコマンドから別のコマンドを明示的に呼び出すことなく、イベントとコマンドをつなげる機能も提供している。
Murat: PureMVC との統合は、最初は PureMVC アプリケーションに IoC を提供する実験的な試みとして開発した。そしてそれが可能であると明らかになった時点で、わたしたちはその作業の成果を公開することに決めた。
PureMVC ユーザにとっての主なメリットは、依存性の取り扱いに依存性注入パターンを使うことによって得られるものだが、DI （依存性注入）の使用はサービスロケータパターンにもとづく PureMVC の本来の利用イディオムを必然的に変更してしまうので、これは同時に最大の欠点でもある。しかし、DI はどのようなアプリケーションにとっても大きな助けとなるし、PureMVC アプリも例外ではないと、わたしたちは信じている。
DI への移行を簡単にするために、Prana の PureMVC 統合は可能な限り柔軟につくられている。たとえば PureMVC プログラマはどのくらいの規模で DI を利用するのかを選択することができる。Prana に PureMVC オブジェクトでないものだけを管理させることもできるし、PureMVC クラスの一部だけを管理させることもできるし、もちろん、PureMVC のものもそうでないものも含め、アプリケーション中に存在するすべてのオブジェクトを管理することもできる。
InfoQ: Prana の利用を一番薦めたい場面（あるいはアプリケーションのタイプ）はどういうものか
Herreman: さまざまな環境でも実行できるようにアプリケーションにある程度の柔軟性をもたせたい場合や、たくさんの設定ファイルを利用していてそれらを一元管理したり外部化したりしたい場合に、Prana の利用をおすすめする。Prana は Spring をベースにしているので、多くの開発者はそのコンセプトや XML の書き方には慣れているだろう。
わたしたちの場合、e ラーニングのプラットフォームを開発したのだが、利用者は自分たちのニーズに合わせてそれをカスタマイズしたがっていた。プラットフォームをホスティングして以後、これらのあらゆるカスタマイゼーションを可能にする仕組みがわたしたちには必要だった。IoC がなければ、それぞれのカスタマイゼーションごとにソフトウェアの別のバージョンをコンパイルしなければならなかっただろうし、XML かデータベースをもちいた独自のコンフィギュレーションシステムを開発することになっただろう。それらをメンテナンスするのは悪夢であったに違いない。かわりに、わたしたちはカスタマイゼーションごとにアプリケーションコンテキストを作成し、どのユーザがログインしたかに応じて対応するコンテキストをロードすればよい。そして、さらにクールなのは、データベースから設定を読み込む ASP ページをもとに、オンザフライでアプリケーションコンテキストを生成できることだった。
InfoQ: Prana の長期的なプランについて教えてほしい
Herreman: 一番重要なのは IoC コンテナだと考えている。コンテナとしての堅牢さを保証できる 1.0 リリースを出したい。これまでのところコンテナ自体はかなりよいものになっているが、まだ改善の余地はあるし、Spring のたとえば親 Bean や Auto Wiring といった機能を追加することだってできる。あと、ドキュメントの整備も必要だ。また、Cairngorm や PureMVC などの拡張をメインのコードベースからは削除して別の拡張ライブラリとしてリリースするという話を、開発チームと進めている。これはリリース管理面でメリットをもたらしてくれるだろう。
わたしは AOP （アスペクト指向プログラミング）フレームワークについても作業を始めたが、ActionScript 3 の制限のために壁にぶつかってしまった。AOP の背後にある中心的なアイデアは、実行時に一連のインタフェースを実装する動的プロキシのメカニズムに基づいた、新しい型のオブジェクトを生成することだが、これは ActionScript 3 では実現できない。これについては Adobe JIRA に問題を登録しておいたので、みなさんがこの件についてアイデアを共有し投票をしてくれるとうれしい。この問題は http://bugs.adobe.com/jira/browse/ASC-3136で見ることができる。
それ以外の点に関しては、しっかりと定まったロードマップはない。わたしたちは他の開発者からの提案には常にオープンだし、新しいアイデアや洞察が得られれば、新機能の導入や改良を行っていく。チームに加わりたい開発者からの連絡も待っている。
原文はこちらです：http://www.infoq.com/news/2008/10/prana-framework-actionscript-3