こんにちわ、masumasuです。
7月に入り、日に日に暑くなってまいりました、皆様はいかがお過ごしでしょうか。
今回は、現在の業務でEU-CUBEに触れており、SymfonyとEC-CUBEのRoutingの違いで躓いたのでその箇所について書いていきます。
Symfonyのルーティング
Symfonyでは、ルーティングは明示的に config/routes.yaml や annotations（コントローラに書くPHPDocスタイル）、または attributesなどで定義されています。
URLと処理を結びつけるこのルールにより、どのエンドポイントでどのコントローラーが呼び出されるかを明確に制御することが出来ます。
例えば以下のように設定します：
# config/routes.yaml
product_list:
path: /products
controller: App\Controller\ProductController::list
もしくは以下のようにアノテーションで定義します：
#[Route('/products', name: 'product_list')]
public function list(): Response {
// 処理
}
EC-CUBEのルーティングの特徴
EC-CUBEもSymfonyのルーティング機構をベースにしていますが、独自の拡張や仕様があります。
まず、EC-CUBEのルート定義は src/Eccube/Resource/config/routing.yml に集約されており、そこに独自のプラグインやフロント、管理画面、マイページのルートが分割して記述されています。
さらに、プラグイン単位で Plugin/YourPlugin/Resource/config/routing.yml を用意すれば、独自のルーティングも簡単に追加することができます。
また、EC-CUBEではコントローラークラスも規約に基づいて配置されており、/admin や /mypage などのセクションによってディレクトリが分かれています。
ルーティングパスも自動生成的な部分が多く、Symfonyよりも構造的に制約があります。
主な違いまとめ
| 項目 | Symfony | EC-CUBE |
|---|---|---|
| ルート定義場所 | 柔軟に選べる（YAML, PHP, Attributes） | 固定パターン（routing.yml） |
| カスタマイズ性 | 高い | 高いが、EC-CUBEの構造に合わせる必要あり |
| 自動生成ルート | 無し（明示的に定義） | 一部テンプレートや機能で自動解釈される |
| プラグイン対応 | 自由に組み込み可能 | プラグインディレクトリごとにルート定義可能 |
まとめ
今回はSymfonyとEC-CUBEのRoutingの違いについて書いていきました。
ご覧いただきありがとうございます。