なぜ、EC-CUBEはSilexを採用したのか

EC-CUBEが目指すものを実現するためにビジネスと技術の両方から考えた上での、Silex採用です。

EC-CUBE3の目的

EC-CUBEをECサイトだけでなく、ECアプリケーションのプラットフォームへ進化させる
ユーザ層の拡張

そのために実現したい技術

プラグイン競合の解消
WebAPIの実装
コアアップデートの提供
UIの刷新
モダンなPHP開発手法

以上の観点で、社内外含め議論を重ねた上で、EC-CUBE3では、これまでの独自実装も活かしつつ「FWの採用」を決めました。

しかし、PHPのFWは、現在数多く存在します。
では、なぜ、その中でSilexを選んだのかをお伝え致します。

なぜ、EC-CUBEは数あるFWの中からSilexを採用したのか

FWの採用を決定したとはいえ、

レンタルサーバで動くのか
FWとしての縛りがきつすぎないか

などの課題がありました。
EC-CUBEを利用して構築されたサイトの多くがレンタルサーバ上で運用されているため、レンタルサーバで動作することが要件となっています。
また、FWとしての縛りがきつすぎると、カスタマイズの自由度が下がる懸念と、学習コストが高くなると考えられることから、「お作法」的な部分をできるだけ排除したいと思っていました。

その中で、主流なFWである以下を候補としてピックアップしました。

CakePHP
Laravel
Silex
Symfony2
オレオレFW

前述の理由からオレオレFWは却下。
次に、SymfonyComponentsを利用することが主流となっている流れを汲みたいため、CakePHPを候補から外しました。

残るLaravelとSilex、Symfony2ですが、

Laravel：レンタルサーバでの動作要件に合わない(Laravel4でもPHP>=5.4)
Symfony2：学習コストが高過ぎる

以上の理由と、パッケージで配布する際にEC-CUBEで利用していないライブラリを同梱したくないという意図から、Silexにて必要なライブラリを取り込んで行こうという方針に決定しました。

消去法で決めたのか

これまでの説明では、消去法での選定となって見えますが、そうではないポジティブな理由も存在します。
EC-CUBEのビジネスロジック部分は、大きく手を加える必要がないほど、ECサイトとしての機能をしっかりと備えています。
現在、EC-CUBE3の開発は「乗せ換えフェーズ」と位置付けたリファクタリングを行っており、単純にSilex上で動作するように乗せ替えていっております。
この乗せ換えフェーズにおいて、FW部分が薄いことにより、既存のビジネスロジックを活かしたまま利用できる箇所が多く残ります。
他のFWを利用した場合、ビジネスロジックの変更が必要になるなど、乗せ換え自体が大きな壁となっていたでしょう。

以上がEC-CUBEがSilexを採用した理由のすべてとなっております。

まだ手探りで開発を進めている発展途上な状態ですが、今後共どうぞよろしくお願い致します！
コミッターも随時募集しておりますので、ご指南いただけると幸いですm(_ _)m
EC-CUBE -GitHub