初めに
設計については、ほとんど何も知らない、駆け出しエンジニアです。
参考書を読んでも、何となくわかるけど、実際に手を動かすと何にもできない状況を変えたくて、勉強記録を残していこうと思います！
環境
- php 8.2
- laravel 11.0
laravelにしたのは、業務で使うからです。
設計の勉強なので、バージョンとかは適当です。
勉強内容
本だけ読んでもよくわからないので、まずは手を動かそうということで、
ネットに落ちているクリーンアーキテクチャーのサンプルコードを写経して、疑問点を調べていくという形で行います。
本題
ということで、第一回目の勉強記録です。今回写経したコードはこちら
app
├── Console
├── Entities
│ └── User.php
├── Exceptions
├── Http
│ ├── Controllers
│ │ └── UserController.php
│ ├── Middleware
│ └── Requests
├── Providers
├── Repositories
│ ├── Contracts
│ │ └── UserRepositoryInterface.php
│ └── Eloquent
│ └── UserRepository.php
└── UseCases
└── GetUser
├── GetUserRequest.php
├── GetUserResponse.php
└── GetUserUseCase.php
ユーザーを登録するだけの簡単なシステムですね。
写経後の感想
思うのですが、設計のしっかりしたコードって、記述量自体は増えますよね？
やることは単純なのに、作成するファイルが結構ある...
今回の写経で疑問に思った点はこちらです。
- Controllerって何のためにあるんだろう？
- Interfaceって何のためにあるんだろう？
主にこの2点です。きっとエンジニアの人には何言ってんだこいつと思われていることでしょうw
まずはControllerについて、いろいろ調べていきます。
調べたこと
さすがに、MVCという設計手法くらいは知っているのですが、何となくの理解で終わらせてきたところもあるので、これを機に自分の中で納得できるまで考えます。
MVCモデルとは？
よく見る図です。
以下がざっくり私の理解です。
MVCモデルのそれぞれの役割
- Model
ビジネスロジック、データアクセスなどを行う場所。システムの中身 - View
名前の通り、アプリの見た目（UI）の部分。システムの外側。 - Controller
ModelとViewの仲介役。Viewから受け取ったデータをModelに渡す、Modelによって処理されたデータをViewに渡す役割
Controllerについての詳細
MVCの中で特に私の理解が曖昧なのがControllerです。
Controllerについて調べると、だいたい以下のようなことが書かれています。
Controllerとは
- Viewページやユーザー操作を受けて、その操作に対して、Model側に処理を指示する
- Modelの処理結果を受け取って、Viewに出力するように指示する
よく耳にするのが、「Controllerに処理を記述してはならない」 という言葉です。
Controllerの責務はあくまで上記の通りの仲介役で、具体的な処理の記述はModelで行うということですね。
ここで私は疑問に思いました。
これControllerいる？
「ModelとViewの仲介役」という役割は、いまいち必要性を感じません。だって、仲介役なんて介さずにViewからModel呼べばいいじゃんって思います。
例えば下の図のように、ユーザーのアクションをViewで受け取り、ViewがModelの処理を呼び出すのではダメなんでしょうか？
（本当に設計初心者なので、意味わかんないこと言ってても勘弁してください）
Controllerはなぜ必要なのか？
では、この疑問を解消するべく調べていきます。
まず詰まったのが、「Controllerにどこまでの役割を持たせるのか」という境界が人によって割と曖昧という点です。
「ControllerはViewとModelの仲介役」というのはどこの説明でも言われていることですが、具体的に何をどうするのがControllerなのかは人によってまちまちで混乱してしまいました。
そんな中で見つけたのがこちらの記事です。
割と詳しくControllerにどういった役割を持たせるのか記述されていました。
ただ、それだけじゃなく、なるほどなと思ったことが、以下の言葉です。
今回はWebMVC、とりわけRailsやFuelPHPなどのフレームワークに準拠した話をするつもりで、それ以外の事例(iOS/AndroidアプリにおけるMVCなどはまた特徴が異なるように思います)
初歩的なことなのですが、Webアプリケーション、iOS/AndroidアプリにおけるMVCを同一のものだと思っていました。だから、人によって言っていることがばらばらだったんですね。
ただ、これがわかったところで、
Controllerいらなくない？という疑問の解消には至りません。
いかにContorollerの役割がその時々で変わると言っても、Controllerは何のためにあるのか、その理由は、どのフレームワークでも共通するのではないでしょうか？
そんな中で見つけたのがこちらの記事です。
V が M の操作メソッドを呼ぶのはMVCではない！！！！！
一番初めに書かれていました笑
MVCの前提として、以下の決まりごとがあるようです。
MVCのルール
- ViewはModelの操作メソッドは呼ばない。呼んでいいのはModelのデータ取得用メソッドだけである
- Model の操作は View 自身で処理せず、かならず Controller に一度渡す
では、この決まりごとによってどんないいことがあるのかを見ていきます。
Controllerの恩恵
一言で言うと、「疎結合にできる」です。
ViewとModel間で直接やりとりをするというのは、結びつきが強くなり、改修が大変になってしまいます。
なぜなら、ViewとModelは1対１対応しないからです。
具体的には、以下のような場合があります。
View1でModel1,2の処理を発火し、View2でもModel1.2の処理を発火するような場合です。
この場合、View1の発火イベントのために、Model1に処理を追加した時、関係ないView2にまで影響が出る。というような事が起こりかねません。
ViewやModelの数が増えれば、もっと複雑になっていきます。
そこでControllerです。
複雑な構成が一気にシンプルになりました。
結局Controllerって何なのさ？
Controllerの説明で、「ModelとViewの仲介役」と表現している記述がたくさんありました。（というかほとんどこう書かれていました）
この言葉は、間違ってはいないけど、誤解するよな〜と思います。
まるで、ModelとViewはそのままでは繋げられないから、Controllerを繋ぎ役にしないといけないとでも言いたげな言葉です。
Controllerの役割は真逆で、「ModelとViewを分けるためのもの」いわば仕切りのようなものだと思います。
（日本語のせいで、理解するのにだいぶかかった、、、）
結論
理解したこと
- MVCとは、ビジネスロジックと、クライアント側の処理を分割し、疎結合にするための構成である
- ControllerをModel（ビジネスロジック）とView（クライアント側）の間に挟むことで実現している
今回は、Controllerの話で終わってしまったので、第二回は、こちらの疑問を解消していきたいと思います。
Interfaceって何のためにあるんだろう？
※Controllerのことを仕切りに例えましたが、これはあくまで私の中での理解になります。MVCについて、自分の言葉で説明するとしたらこうだなと思っただけで、適切ではないかもしれませんが、ご了承ください。
参考
https://qiita.com/riku-shiru/items/2bed096e106e72e0b58a]
https://qiita.com/MasashiFujiike/items/5c1c3e92c0289812a952
https://nekogata.hatenablog.com/entry/2013/11/11/075234