LoginSignup
7
7

More than 5 years have passed since last update.

@solid_red

今更Laravel入門(v5.6) - 1 - Laravelの初期構成を詳しく見てみる

Last updated at Posted at 2018-03-25

なぜ今Laravelなのか

小さな制作会社をやっています。
WEBに限らず、アプリや業務系も作ってます。

昔はちょこちょこPHPで開発を行っていたものの、最近は業務系のシステムが多かったため、WEB開発ではもっぱらJavaやPython、たまにRubyで開発を行っていました。PHPを使うのはもっぱらWordpressの開発です。
使っていた頃は過渡期だったというのもありますが、以前のPHP（v5.6以前）にはあまり良い思い出がなく、度々悩まされていた記憶があります。

それでもやはりPHPは現在でも主流の言語の一つであり、扱いやすく、人気があります。
知り合いなどからも、「最新のPHPはそんなことないよ。使いやすくなってるよ。」と度々聞いてました。

最近のPHPのフレームワーク事情を見ていると、どうやら今はLaravelというものが人気らしい。
以前はZend FrameworkやCakePHPなどの名前をよく聞きましたよね。

知り合いの方が数年前にLaravelの本を出していたのも思い出し、「Laravel、お勉強してみようじゃないですか！」と思い立ったわけです。
本を出された方は今Laravelのカンファレンスなどにて講演もされているようですが、まずは自分でゆっくり勉強して理解を深めていければなと思います。

インストール

これはわざわざここで書かずとも公式サイトなり、他の方が書かれている記事を見るなりすればすぐに分かるかなと思います。
探せばサンプルは星の数ほどあります。

などなど。

プロジェクト作成

これから勉強で使うプロジェクト名は「study_laravel」にします。

composer create-project --prefer-dist laravel/laravel study_laravel

ディレクトリ構成

と、ディレクトリ構成を書く前に一覧を確認したところで「LaravelはMVCモデル」と前段階の知識を入れていた私は困惑します。
Modelディレクトリ無いじゃん、と。
しかし、公式を見れば納得します。

When getting started with Laravel, many developers are confused by the lack of a models directory. However, the lack of such a directory is intentional. We find the word "models" ambiguous since it means many different things to many different people. Some developers refer to an application's "model" as the totality of all of its business logic, while others refer to "models" as classes that interact with a relational database.

要約すると、「Modelと言う概念は、多くの開発者にとってそれぞれの意味を持ち、非常に曖昧なものなので、あえてディレクトリを設置していない」、とのことです。
MVCモデルを登場の頃から使っている方々はお分かりになるかと思いますが、確かにMVCモデルのModelに関しては、各開発者の間で「こうあるべき、あああるべき」と、血で血を洗うような議論が巻き起されてきた歴史があります。
そのような歴史を鑑みて、あえて設置せず「各々自由に作れ」って言ってるんですね、Laravelは。
素晴らしい選択だと思います。

それを踏まえた上で、各ファイルやディレクトリがなんの役割を持っているか、出来るだけ注釈を添えて見てみます。

ディレクトリ & 初期ファイル一覧

  • study_laravel
    • app
      • Console
        • Kernel.php #オレオレartisanコマンドの追加や、バッチ処理などを設定
      • Exception
        • Handler.php #エラーログの表示の仕方を設定
      • Http
        • Controllers #コントローラディレクトリ
          • Auth / ForgotPasswordController.php #デフォルトで入っているログイン機能。パスワードを忘れ処理
          • Auth / LoginController.php #デフォルトで入っているログイン機能。ログイン処理
          • Auth / RegisterController.php #デフォルトで入っているログイン機能。登録処理
          • Auth / ResetPasswordController.php #デフォルトで入っているログイン機能。パスワードリセット処理
          • Controller.php #コントローラのベースクラスが書かれている。コントローラを作る場合、基本的にこのベースクラスを継承する
        • Middleware
          • EncryptCookies.php #Cookieの暗号化を設定
          • RedirectIfAuthenticated.php #ログイン後などの認証ユーザーが認証外の操作をした際の飛ばし先などを設定
          • TrimStrings.php #リクエストに含まれるinputの値を自動でトリミングする機能の設定
          • TrustProxies.php #プロキシの管理。信頼するプロキシなどの設定
          • VerifyCsrfToken.php #CSRF検証から除外するURIの設定
        • Kernel.php #ミドルウェアの設定
      • Providers　
        • AppServiceProvider.php #初期処理。ほぼ何も書かれておらず雛形的なもの。
        • AuthServiceProvider.php #Auth処理。ほぼ何も書かれておらず雛形的なもの。
        • BroadcastServiceProvider.php #ブロードキャスト処理。WebSocketなどを使用した、リアルタイムでライブ更新されるような機能を作成する際に使用する。ほぼ何も書かれておらず雛形的なもの。
        • EventServiceProvider.php #イベントリスナー処理。アプリケーションで発生する様々なイベントを一括で管理できる
        • RouteServiceProvider.php #ルーティング起動処理。routeディレクトリ内の設定を読み込み、ルーティングを管理する
      • User.php モデルファイル相当#認証に使用するカラム、及び配列化した際に暗号化するカラムの設定。usersテーブルのもの。
    • bootstrap
      • cache
        • packages.php #キャッシュするパッケージの設定
        • services.php #キャッシュするサービスプロバイダの設定
      • app.php #フレームワークの初期化を行い、autoloadingを設定
    • config
      • app.php #アプリケーション名やアプリケーションURLなどの基本設定
      • auth.php #認証系の基本設定。デフォルトではusersテーブルが使用される設定になっているが、ここで追記、変更などをする事で別のテーブルで管理することもできる
      • broadcasting.php #イベントブロードキャストの設定。WebSocketを使用したリアルタイム更新などを行う際に、ここに設定を記述する
      • cache.php #APC、memcache、databaseキャッシュなど、キャッシュに関する設定
      • database.php #mysql、sqlite、pgsqlなどの各データベース接続情報の設定
      • filesystems.php #アプリでファイル保存を扱う場合の、ローカルやS3など保存設定。
      • mail.php #メール機能の、ドライバ、ホスト、ポートなどの設定
      • queue.php #非同期処理を行うキュー機能の設定。database、sqs、redisなども使用できる模様
      • services.php #サードバーティー製のサービス設定。mailgun、ses、Stripeなどがデフォルトで設定されている。
      • session.php #セッション設定。保存方法や、暗号化の有無など。
      • view.php #ビューのパス、ビューテンプレートのコンパイル後のパスなどの設定
    • database
      • factories
        • UserFactory.php #構築時に用意されているusersテーブルに対するファクトリー（各カラムの初期データ設定値などを自動で入れ込むことが出来る機能）ファイル。必ずしも使う必要はない
      • migrations
        • 2014_10_12_000000_create_users_table.php #usersテーブルマイグレーションファイル。必ずしも使う必要はない
        • 2014_10_12_100000_create_password_resets_table.php #create_password_resetsテーブルマイグレーションファイル。必ずしも使う必要はない
      • seeds
        • DatabaseSeeder.php #seederファイル。ファクトリーファイルに設定されている各テーブルの初期値を呼び出し、各テーブルに初期データを挿入するなど、テストデータ作成の際などに使用する。
    • public
      • css
        • app.css #アプリ作成時に最初から入っているCSS
      • js
        • app.js #アプリ作成時に最初から入っているJS
      • .htaccess
      • favicon.ico
      • index.php #アプリケーション立ち上げ時にまず最初に呼ばれるindex.phpファイル。この中で、オートローダーにて各ベンダーファイルを読み込み、フレームワークの初期化を行った後、アプリケーションを実行することになる。
      • robots.txt
      • web.config #IIS(WindowsServer)などで使用する際に使う設定ファイル。
    • resources
      • assets
        • js
          • components / ExampleComponent.vue #vue.jsを使用する際のサンプルコンポーネントファイル
          • app.js #アプリケーションにおけるJavascriptの全ての依存関係を読み込む設定が書かれている。初期ではbootstrapとvue
          • bootstrap.js #bootstrapプラグインの読み込み
        • sass
          • _variables.scss #各設定値が書かれたSCSS。当然ながらコンパイル前
          • app.scss #初期では上記の_variables.scss、WEBフォント、BootstrapなどをインポートしているSCSSファイル。当然ながらコンパイル前
      • lang #言語設定ディレクトリ。エラーメッセージなどをひとまとめに管理する。アプリ構築時は英語しかない。
        • en
          • auth.php #認証時のメッセージ管理
          • pagination.php #ページネーションのメッセージ管理
          • passwords.php #パスワードに関するメッセージ管理
          • validation.php #バリデーションに関するメッセージ管理
      • views #ビューディレクトリ
        • welcome.blade.php #初期ファイル。初回起動時にこのテンプレートが呼ばれ、表示される
    • routes #ルーティング設定ディレクトリ
      • api.php #API使用時のルーティングを設定する。APIミドルウェアを経由し、セッションを使用しないステートレスな通信を行う機能のルーティングに主に使用。
      • channels.php #WebSocketなどブロードキャスト機能使用時のルーティングを設定する
      • console.php #コンソール使用時のルーティングを設定する
      • web.php #WEB使用時のルーティングを設定する。WEBミドルウェアを経由し、セッション、CSRFトークンを使用した通信を行う機能のルーティングに使用する
    • storage
      • app
        • public #一般公開へのアクセスを許すファイルを格納し、public/storageからシンボリックリンクを貼ることで、ファイルの配布を可能にするディレクトリ
      • framework
        • cache #キャッシュデータ格納ディレクトリ
        • sessions #セッションデータ格納ディレクトリ
        • testing #テストデータ格納ディレクトリ
        • views #viewの「キャッシュ」データ格納ディレクトリ
      • logs #ログデータ格納ディレクトリ
    • tests
      • Feature
        • ExampleTest.php #機能(Feature)テストのサンプルコード
      • Unit
        • ExampleTest.php #ユニットテストのサンプルコード
      • CreatesApplication.php #テスト環境起動用のスクリプトファイル
      • TestCase.php #テストケースを記述するファイル
    • vendor
      • (ベンダーディレクトリ多数)
  • .env #アプリケーションの基本設定値を設定する、環境設定値ファイル。ここに記述した値は、PHPスーパーグローバル変数の$_ENVにて取得出来るようになる
  • .env.example　#上記envファイルのサンプル
  • .gitattributes
  • .gitignore
  • artisan　#アルチザンと読む。様々なオプションを使用し、このファイルを実行することで、様々なことが行える。
  • composer.json　#composer設定用json
  • composer.lock　#composer設定用lockファイル
  • package.json　#npmのバージョン管理ファイル
  • phpunit.xml　#PHPUnitの設定ファイル
  • readme.md
  • server.php　#サーバー起動設定ファイル
  • webpack.mix.js　#全アセットコンパイルのエントリポイントファイル。アセットのコンパイル対象ファイルやコンパイル後のファイル名を記述する

※　各子孫ディレクトリの.gitignoreは記述を省いています。随所にありますが、これはプロジェクトをgit管理をする際に、細かく管理対象を設定するために気を利かせて設置してくれているようです。
※　vendorディレクトリに関しては、中身を記述しません。僕が死にます。機会と気力があれば全て書きます。

まとめ

書いていて思ったのがなんのオプションも指定せずにアプリケーションを作成すると、ファイル数がかなり多いことに気づきます。
ただ、これはきちんと各機能、処理ごとにきちんと区分けされている結果であり、ネガティブな事ではないと思います。

実際にシンプルなフレームワークであればあるほど、作り手の能力によってディレクトリの構成や、可読性の良し悪しなどが著しく変わります。
それがのちにプロジェクトに多大な影響を与える事もありますので、Laravelのこのボリューム感は丁度良いとさえ思えます。

それでは構成内容もあらかた分かったところで、次回からは早速サンプルアプリケーションを使用して、実装していきたいと思います。

※　上記構成内容について間違った点などがあれば、ご遠慮ない突っ込み、お願いします！

7
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
7