こんにちは。
EC-CUBE運営チームの高橋です。
EC-CUBEがver.3になるため、その情報発信・共有の場として、Qiitaを使わせていただくこととなりました。
よろしくお願い致しますm(_ _)m
さて、表題についてです。
なぜ、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