読者です 読者をやめる 読者になる 読者になる

作業ノート

様々なまとめ、雑感など

Silexを試してみた(7) - その他と雑感

最後に今回試したSilexに関するその他のまとめと雑感について。

今回試さなかったこと

Controller Providers

index.phpに、簡単にRouteが定義できるとはいえ、その数が多くなるとそれらをまとめて管理したくなると思う。そういうときに使えそうなのがController Provider。

ドキュメントを読むと、これはRouteの定義部分をControllerProviderInterfaceをimplementしたクラスで定義するものらしい。

インターフェイスにはconnectメソッドが定義されていて、引数がSilex\Applicationのインスタンス。そのメソッド内でRouteを定義する。

Middlewares

定義したRouteの実行前、実行後に実行することができるフィルターのようなもの。

メソッドとしてはbeforeafter。その名の通り、それぞれRouteの実行前と実行後に実行される。またclientにレスポンスが送られたあとに実行されるfinishメソッドもある。

beforeメソッド、afterメソッドは、アプリケーション(Silex\Application)と、Routeに定義できる。

アプリケーションに定義したときは、そのアプリケーションで管理しているRouteすべてでその前後で実行される。

Routeに定義したときは、そのRouteが実行される前後で実行される。

両方定義されているとき、beforeメソッドなら

  1. アプリケーションのbeforeメソッド
  2. Routeのbeforeメソッド

の順で、afterメソッドなら

  1. Routeのafterメソッド
  2. アプリケーションのafterメソッド

の順で実行される。なお、これらのメソッドを定義するときに優先順位がつけることができるようで、これでメソッドの実行順を制御する。

雑感

アプリケーションをSymfony2のコンセプトに従って体系的に開発、管理するSymfony2は、ディレクトリ構造が複雑で必要なパッケージも多い。今回試したサンプルをSymfony2でやろうとすれば、ディレクトリ構造の把握、app/consoleコマンドの使い方、そしてコードの書き方など、試すまでに必要な知識と工程が多くなる。

それに比べると、SilexはSilex\Applicationのインスタンスを生成、実行するためのphpが一つあればよく、そこにいくつかのコードを記述すればよいので、とりあえず試すには簡単でとっつきやすい。

それは本家のドキュメントにもあらわれており、Silexを試す上で必要な情報は、本家のUsageを読めばよい。これが1ページで構成されていることからも、使えるようになるのにそう時間がかからない事が分かると思う。

一方で、SilexはSymfony2のコンポーネントを多く利用している。Silexでは、提供された機能の利用や実装はService Providerを用いる。この辺りの考え方はSymfony2と変わらない(Symfony2の場合は、Service Container)。よって、Symfony2の経験がある人なら、Silexを使うことはそこまで難しくない。

試しながらSilexの用途を考えてみたが、もし自分がSilexを使うとしたらWeb APIの構築で使ってみたい。

APIのレスポンスタイムを考えると、frameworkの実行時間に時間をかけたくないためにframeworkを使わない実装を考えるが、そうすると運用コストがかかりそう。だからといって、Symfony2はやりたいことに対して大きすぎて、必要ないところでコストがかかりそう。

Silexだと全体的にコンパクトで、APIの実装で必要なjsonでのレスポンスやエラー処理も比較的簡単に実装できる。ある程度大きくなれば、適切なサイズのコントローラとして管理することもできる。Web APIの管理系は、Twigでテンプレートを使ってページを作成できるし、SilexはWeb APIを構築する上では十分の規模ではなかろうか。

ただし、今回Silexのパフォーマンスは確認していないのでその点は気になるが、現実的な選択肢としてありだと思う。

あとは試すのが簡単という点から、モックアプリのために使うか。

その他

せっかくなので、自分で試しに書いてみたプログラムをGitHubに上げた。

te2u/Silex-sample

1コミット1エントリとしてまとめた。

参考

関連