はじめに

先日、松戸市内でLaravelドキュメントを読む勉強会を開催しました。この時の開催レポートです。当日は松戸駅近くのイベントスペースFANCLUBをお借りしましたー。ありがとうございました。

趣旨がちょっと変わったぞ・・・？

Laravelのドキュメントを原文で読むことでLaravelへの理解を深めること英語力を向上させることが目的の一石二鳥イベント。ただ、それだけではなくドキュメントを読んでいくうちに、段々と設計思想の話にもなり、非常に学びの多い会となりました。
特に、私が所属しているJoolenには、EC-CUBEのスペシャリストがおり、その方との会話の中での気づきが大きかったのでこちらを中心に書き残しておきます。

今回、話題にできたテーマは以下の通りです。¹

共通点

`.env`を使っていること

データベースへの接続文字列などは.envファイルに持たせることができます。
本番環境では、.envファイルではなく環境変数から設定を取得できるので、セキュリティの観点から、その様にしましょうという話で盛り上がりました。
もちろん、APP_ENVの指定で、参照する　.envファイルを切り替えることができることも同じです。EC-CUBE4系以降でも使えるテクニックです。
切替え方法が参考になる記事

composerを使っていること

共にcomposerを使うことができるので双方ともにパッケージのインストールなどで悩むことはあまりなさそうです。ただ、composer create-projectで雛形を作れることに、EC-CUBE経験者は驚いていました(パッケージをインストールする以外にも機能があったんだ！)

DI(Dependency Injection)が使える

EC-CUBE4系もLaravelもDIを使うことができます。ただし、Laravelはコンストラクタだけではなくメソッドでもインジェクションをすることができます。テストがしやすくて良いですね

相違点

まぁ、全く異なるフレームワークなので相違点ばかりなのは当たり前ですが。。。

ルーティング方法

EC-CUBE4系では、Controllerのアノテーションでルーティングや返すテンプレートを定義します。
EC-CUBEのController(抜粋)

    /**
     * 会員登録画面.
     *
     * @Route("/entry", name="entry")
     * @Template("Entry/index.twig")
     */
    public function index(Request $request)
    {
     ...
    }

一方、Laravelではroutes配下のweb.phpなど、Routingは独立しています。

<?php

/*
|--------------------------------------------------------------------------
| Web Routes
|--------------------------------------------------------------------------
|
| Here is where you can register web routes for your application. These
| routes are loaded by the RouteServiceProvider within a group which
| contains the "web" middleware group. Now create something great!
|
*/

Route::get('/', function () {
    return view('welcome');
})->middleware('auth');

コレは双方にとって、少し新鮮だった様です。ちなみに、Laravelのルーティングファイルは分割することができます。(質問された)

<?php

namespace App\Providers;

use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
use Illuminate\Support\Facades\Route;

class RouteServiceProvider extends ServiceProvider
{
    /*
     * This namespace is applied to your controller routes.
     *
     * In addition, it is set as the URL generator's root namespace.
     *
     * @var string
     */
    protected $namespace = 'App\Http\Controllers';

    /*
     * Define your route model bindings, pattern filters, etc.
     *
     * @return void
     */
    public function boot()
    {
        //

        parent::boot();
    }

    /**
     * Define the routes for the application.
     *
     * @return void
     */
    public function map()
    {
        $this->mapApiRoutes();

        $this->mapWebRoutes();

        //
    }

    /*
     * Define the "web" routes for the application.
     *
     * These routes all receive session state, CSRF protection, etc.
     *
     * @return void
     */
    protected function mapWebRoutes()
    {
        Route::middleware('web')
             ->namespace($this->namespace)
             ->group(base_path('routes/web.php'));
    }

    /*
     * Define the "api" routes for the application.
     *
     * These routes are typically stateless.
     *
     * @return void
     */
    protected function mapApiRoutes()
    {
        Route::prefix('api')
             ->middleware('api')
             ->namespace($this->namespace)
             ->group(base_path('routes/api.php'));
    }
}

ディレクトリ定義の自由さ

よく言われることですが、Modelsディレクトリが無いことに驚かれました。ただ、一方でこれはLaravelを利用する技術者が自らのベストプラクティスを適用できるという意味にもなります。逆にイケてない設計をすると、あとあと苦労するという噂もありますが。。。
EC-CUBEではいわゆる、リポジトリパターンをきっちり採用していますのでLaravel側でも同じ様な設計をすることで、双方の人材交流はやりやすくなるかなー、と思いました。
Laravelでリポジトリパターン
まぁ、基本的にはその企業やチームの文化やスキルセットに合わせた設計で良いか、というオチでしたが。。。

まとめ

EC-CUBE経験者とLaravel経験者で意見交換をすることで、思いも寄らない気づきをたくさん得ることができました。参加してくださった方々、本当にありがとうございました。

pretty urls以降は、時間の都合でざっと眺めた程度になっちゃいました ↩