Zend Framework その7年

あけましておめでとうございます。 Zend Framework 日めくり Calendar 2012の1日目としてお送りします。この日めくりカレンダー、前月に流行ったAdventカレンダーの、アイデアフォーク(パクリ)となっております。記事書いていただける方を募集中です。ぜひatndへのリンク先からご登録ください。

以下は前編としてお送りします。なお、この記事はかなり書きなぐりでつづっており、間違いがありましたらご一報ください。

Zend Framework って？

この記事をご覧になる方はある程度予備知識がある方が多いと思いますが、改めてZend Framework(以下、ZFと表記)についてご紹介します。

ZFの概要については以下の記事がよく参照されてるかと思います。

(phpproの記事は全般的に古くなってので注意書きを付け加えてもらいところですが。)

ZFの思想・標語は、

コンポーネントライブラリーであり、かつフレームワーク
PHPにとって最良の手段を提供する
クソッタレをリファクタしてやる！という点があげられます。（クソッタレをリファクタしてやる」については、現在リードデベロッパーのマシューが2008年頃のカンファレンスの発表で"Refactoring Sucks"と述べてる点を踏まえて記載）

なぜ、この設計思想なのかはZFの構想が発表された2005年の状況と、さらにそれまでのPHPを取り巻く状況を振り返るべきでしょう。そして、Zend Framework 2のリリースを迎える今年、 2005年の発表からの変遷について確認したいと思います。

Webアプリケーションにおけるフレームワーク

ここではフレームワークとは何かという主張は一旦さけ、今日Webアプリケーション作成において多大な影響を与えたフレームワークについて挙げてみます。

struts (ver 1)
Spring
Ruby on Rails
Sinatra

struts

Webアプリケーションで初めにフレームワークとして定着されたとされるstrutsですが、その功罪については以下に語られる通りだと思います。

strutsで構築されたシステムの問題点は単にstruts自体の設計に起因するものではないですが、 Rails登場までの"フレームワーク"に対する言葉に対し「どの開発者も同等のコードを書くの強いられてるんだ！」というイメージが定着してしまった一因の代表格として、かわいそうなことにstrutsは今後も虐げられると思われます。 strutsの設計上の問題は上記参照先で述べられた通りですが、なぜver1.1のまま保守追加が行われるのか、なぜver1の問題点を改良したstruts2は広まらなかったのか、開発手法・テスト・設計・教育・運営などの観点、、、結局のところ単にフレームワークは導入すれば良いものではないことが顕在しています。そしてまた、フレームワークを吟味する際にはstruts1の過ちを繰り替えしてないかという所が一つの指針としてあげられるでしょう。

Spring

Springは、そのMVCについては"Apache Struts Webフレームワークに失望したためであり” というくだりがwikipediaには記載がありますが、単にRequest・Response部分ではなく、 AOPやDIなどの概念が次世代PHPフレームワークで、着目されている箇所でしょう。・・・もっとも数年前には日本の何人かの開発者は取組んでいたわけですが。。

Ruby on Rails

元PHP開発者のDHHが作ったフレームワークとしても話題となったrailsですが、設定より規約と言った迅速にアプリケーションを書くための設計指針は、 "Rails以降"とよばれるPHPフレームワーク第1世代を生んでいくことになります。 (Mojaviはどうした!?)

のちに、Marbとの統合などでrubyコミュニティとフレームワーク・CMSなどと拡散し存在するPHPコミュニティの違いを考えさせられいくこととなります。また、ActiveRecordパターンもPHPコミュニティで話題となるわけですが、 ZF開発初期にてActiveRecordを検討された形跡もあります。しかし、ZFで提供するZend_DbはDBALであり、その経緯については、 Zend_Dbの作者はActiveRecordをどう考えているかなどで分かるでしょう。

Sinatra

先にあげた3つのフレームワークは、ZFが登場する前に存在したものでした。 Rails以降、PHPでのフレームワークによる開発がより定着していくわけですが、そんななかまたRubyから登場したSinatraは軽量フレームワークとして注目を浴び、 PHP界隈でも影響を受けたものがたくさん登場します。

それまでのコンポーネント・フレームワーク

ZF登場以前、もちろんご存知の通り数多くのライブラリやフレームワークがPHPにもありました。え、Mojavi?Ethna?CakePHP? それらについては、ZFのツクリと大きく異なっていますし、影響は垣間見えません。コンポーネント・ライブラリー、フレームワークとして以下のプロダクトがZFを語る上で外せないものです。

Horde、PEAR、Solar、ez components(Zeta)

Horde

PHPでも最も古いフレームワークとも言われるHordeは12年の歴史があり、日本ではガン無視されるライブラリ集の一つです（ホントになぜなんでしょう？） Hordeは現在でも活発に開発されており、実に多くのコンポーネントを備えています。現在PEAR/Zend形式として知られるコーディング規約は、Hordeの規約から流用したものをPEARのコーディング形式として定めたものが普及した形です。 Hordeプロジェクトに関わっていたこともあるMikeはZF開発初期におけるリードを務めていました。(PHP開発者のためのRuby入門のサイトでも知られてますね) では、なぜHordeをZend推奨のフレームワークとする動きがなかったのでしょう？(愚問にもほどがある) もちろん、ZFが目指す強力で拡張性の高く堅牢なプロダクトに合致しないとも言えますが、品質の面で言うと、、 http://twitter.com/#!/hnw/status/85573858530295809

ところで、wordpressでも使われているPEARのText_DiffはのちにHorde_Text_Diffとして引き継がれていくことになります。

PEAR

ZFの開発発表時・そしてそれ以降、ZFはPHP4で作られた古めかしいPEARを置き換えるものだと見なされることが多々ありました。たしかに、ZFコミッターの一人であるPadraicbは、PEARの対等的立場となってしまった点について認める旨をtwitterで述べています。
Symfony2での潮流でフォーカスされるスタンドアローンと疎結合の違いもありますが、PEARとの違いでは一律のメンテナンス性の問題が観点として必要でしょう。 PEARとZFとの関係を見た場合、まるでPEAR開発者とZF側には関わりがないように見えるかもしれませんが、 Cache_Liteの開発者がZend_Cacheの設計を行っていること(経緯は不明)、PEARのメイン運営陣がZFのコントローラを使いFrapiを開発している点は興味深い動向(だった)と言えます。

Solar

海外で言及されることがありながらやはり日本でガン無視されてるフレームワークSolarは、ZFと密接な関わりがあるフレームワークの一つです。(私はkoriymさん以外が言及したのを見たことがないです) なにせSolarの開発者はZFの開発に関わっていますし、ZF現リードのマシューはSolarの開発に関わっていました。 ZFで見られるパターンの一つであるコンフィギュレーションパターン(デフォルトの設定値配列に、コンストラクタなどで上書きの設定配列を渡す形式)はSolrからの影響と言われています。

ez components

現在ZetaとしてApacheインキュベート入りしているez componentsは CMSでのez projectsも知られるプロジェクトです。 CLAを結んでのコントリビュート形式、プロポーザルを経てのマスター入りなど、ZFが品質の面で用いている開発方法に似通った面があります。最近ではTwigのextension部分の開発も行ったPHPコミッター・Derickなど著名なPHP開発者達がezのプロジェクトに関わっています。そしてなりより、ezコンポーネントの開発に参与しているメンバーがSebastian BergmannであるということはPHPUnitインストール時にお気づきのことかと思います。 Zend Frameworkの設立時にも参与したSebastian Bergmannですが、のちにとあるカンファレンスではゲームの台詞"Cake is liar"を引用しながら密結合と疎結合のZFについての発表も行っています。そして、今Java界隈では影響力のあるApache Software Foundationに加入という流れですが、アパッチは有害と考えるというエントリーでも述べられてるようなgithub革命後に各OSSは開発のあり方が問われる昨今、ZFでも開発スタイルが変わっていくことになります

と、ここで述べた以外にもPHP全体の流れ(wordpressほかCMS、ec系ツール)がありますが、冒頭で述べた通りの指針や開発者・利用者の思惑などが入交り開発がスタートされていきます。

（続きは、中編で）

sasezaki/zfhimekuri0101.md