第７章 保守と拡張性が高い構造体に変更する準備

前回まででとりあえず動くものとテストコードの実装まですすみました、今の状態でも開発はすすめることはできますがアプリの機能がおおくなると今のままではコードのメンテナンスは難しくなるかもしれません。

今回はアプリをコードを書くのは一旦やめて、アプリ開発をするときにどういうディレクトリ構造をつくるのがよいのかみていきましょう。

7.1 ディレクトリとファイルの作り方

ディレクトリ構造をつくるまにUNIX的にはディレクトリとはディレクトリファイルのことであり、ファイル名というのは任意の文字でよいことになっています。

とはいえ何も考えず場当たり的に名前をつけていくと一貫性がなく何が何だかわからなくなってしまうので慣例的にこういう名前もしくはディレクトリ構造にする方が無難という考え方があります。

ファイル名について下記のまとめてみました。

ファイル名について

  • UNIX 的にいうところのファイルとは
    • 取り扱う情報の単位、ファイルタイプの意味で使われることがある
    • パソコンの「フォルダ」は「ディレクトリファイル」と言われことが多い
    • 現在は日本語のファイル名も使えるがあまり推奨はしない
    • 正確にファイル名はディレクトリファイル名と組み合わせて表現されるので日本語をファイル名にすると使いにくくなる
  • ファイルディレクトリの構造体について
    • 慣例的な構造体がある Filesystem_Hierarchy_Standard
    • Perl のスクリプトについては名前空間の規則が存在する
    • キャメルケースとスネークケースを使い分ける
    • アプリケーションの実行ファイルはあえて拡張子をつけないことがある

上記の点など考慮すると下記のようなディレクトリ構造になるとおもいます。

完成系のディレクトリ構造のイメージ

dir                       # Application directory
|- bin                    # docker-compose の中で実行するコマンド
|- db                     # データベース関連ファイル
|- doc                    # 参考資料各種
|- etc                    # 設定ファイル
|- lib                    # 読み込みファイル各種
|  |- BeginningMojo       # アプリケーションファイル各種
|  |  +- Controller       # アプリケーションコントローラー
|  |  +- DB               # データベースオブジェクトロジック各種
|  |  +- Model            # コントローラーロジック
|  |  +- DB.pm            # データベースオブジェクトロジック呼び出し
|  |  +- Model.pm         # コントローラーロジック呼び出し
|  |- Test                # テストコード拡張モジュール
|  +- BeginningMojo.pm    # アプリケーション定義
|- local                  # 拡張モジュール各種
|- public                 # 静的なファイル各種
|- script                 # 実行ファイル各種
|  +- bulletin            # アプリケーション実行ファイル
|- t                      # テストコード各種
|- templates              # 画面表示用テンプレート各種
|- .gitignore             # git で管理しないリスト
|- .perl-version          # 実行するPerlのバージョン情報
|- cpanfile               # インストールするモジュールリスト
|- cpanfile.snapshot      # モジュールインストール履歴
|- docker-compose.yml     # docker compose 実行
|- Dockerfile             # docker イメージ作成
+- README.md              # はじめに読む資料

7.2 MVCの考え方

web アプリを開発するときによく聞くのが MVC という言葉ですが、今回紹介している Mojolicious も MVC という考え方で活用するように考えられています。正確には Model 部分は利用者が都合の用意ように活用してくださいということなのですが、大前提として MVC とはどういうことなのかはある程度理解がある方が良いと思います。

MVCについて下記にまとめてみました。

  • MVC の基本
    • Routes: ルーティング、リクエストされたURLを判定
    • Controller: コントローラー、リクエストされたURLごとの挙動の判定
    • Model: モデル、データベースへの登録などのロジック一式
    • View: 画面の表示、変更される値をうめこんだhtmlファイル一式
  • ありがちなwebアプリの実行する順番
    • 端末からリクエスト/list
    • ルーティング/list判定 -> コントローラーlistメソッド -> モデルロジック
    • モデルロジック処理後 -> コントローラーlist -> ビューlist画面描画
    • どんなwebアプリでもMVCで表現できるわけではない
  • MVCはひとつの型なのである程度の割り切りが必要
    • mojo流のMVCの考え方は公式ドキュメントを参考にするとよい
    • MVCの手法を使うとコントローラーとビューは密結合してしまう
    • どのような実装手法をつかったところでシステムが巨大化すると完全に統一することは困難
    • システムが巨大化する兆しがみえたら早急に分離することを検討した方がよい

図にすると下記のようなイメージになると思います。

7.4 まとめ

7.5 次回

今回は保守と拡張性が高い構造体について考えてみました。

ディレクトリ構造については必ずこうしなければいけないということはないですがある程度自分なりの指標をもっておくとものづくりはやりやすくなると思います。

次回は実際に今のアプリの構造体を変更してゆきたいと思います。