Rails,Laravelを使う前に知っておきたいMVCアーキテクチャ
RailsやLaravelを使い始めると必ず触れるのがMVCアーキテクチャですが、プログラミングを始めようとするとRails,Laravelなどのフレームワークの名前が先行しがちです。
フレームワークは当然道具ですので、道具を使うには道具の設計思想を理解していないと使いこなすことはできません。
フレームワークを使い始める前にMVCとはなんなのか？というのを説明できるようにしましょう。
MVCアーキテクチャとは
MVCとは、
- Model モデル
- View ビュー
- Controller コントローラ
Model モデル | ビジネスロジック担当
Modelはビジネスのジックを担当して、データベースとの接続もこちらの層の役割です。いいねボタンを押した時や座席予約システムでお客様の予約情報の保存と空席情報の更新を一括で行うというのは、モデルの役割です。
いわゆるCRUDの実行役もこちらの層の役割です。
Controller コントローラ | 司令塔
コントローラは、ユーザからの入力（フォーム送信）などに応じて、モデルやビューに司令を送り、その結果をユーザ（ブラウザ）にかえす責務をもっています。WebアプリにはRestFullという考え方がありますが、あるURLにGET送信がきたらモデルの一覧、POST送信がしたら新規レコードの作成というようにユーザからのリクエストに対して、実行すべき処理をきめるという役割をもっています。
View ビュー | 表現役
ユーザに対してどういった表現を返すかを決める役割を持つ層です。いわゆるフロントエンドということになると思います。htmlでかえすかjson形式で返すかというやくわりもそうですし、どういうhtmlを返却するかというのもそうです。大抵のMVCフレームワークでは、アクションにたいしてそれに紐づいた形のビューを定義して開発していきます。Railsではerb, slim, haml、Laravelではblade, twig, voltなどのテンプレートエンジンを利用して開発していきます。
MVCアーキテクチャで役割を分割するメリット
初っ端からぱっとMVCアーキテクチャのそれぞれの役割について説明しましたが、この役割を分割する意味というのはどういうところなんでしょうか？
プログラミングの世界特にオブジェクト指向の世界では、責務(=役割)という言葉が頻繁に使われます。単一責務の原則と言ったりするのですが。１つのクラスは１つの責務をこなし、責務外の処理は別のクラスに任せるという設計思想が存在します。 この原則のメリットは、各クラスの責務が分離しているためクラス間が疎結合(お互いの状態を知らなくて良い)に保たれる点です。
クラス間が疎結合（お互いの依存度が低い状態）に保たれていると再利用性が高まり、それぞれのモジュールについて知っておくべき情報（データ）がすくないので、変更に強くなります。
ビューはWebサイトのデザインによって頻繁に修正がはいることが多いですが、デザインの変更はビュー内での変更に止めることができ、コントローラやモデルに影響がでることはないという形で実装できます。
まとめ
- MVCアーキテクチャはモデル、コントローラ、ビューの頭文字をとったもの
- MVCアーキテクチャを採用することで変更につよいシステムをつくれる。
- モデルは、データベースの取得・更新。ビジネスロジック担当
- ビューは、アクションに応じたユーザへの表現をきめる役割。
- コントローラはユーザからのアクションに対して、実行するビューやモデルなどを選定して処理を決める役割。
割と最初にWebアプリを開発した時は「どこに書けば良いの？」というところで不安になりがちですがこうした指針があると幾分開発がらくになるかと思います。アーキテクチャなどと聞くと初心者には難しくて手がだしづらい雰囲気がありますが、RailsやLaravelではある程度きっちり層がわけられていて、それぞれの層でやるべきことがわかるようになっているのでそこまで意識しないでも自然とMVCの形で開発ができると思います。
無意識的にかけるのでよいとする考えもありますが、ぜひこれからフレームワークを使う方はコードを書き始めるときに責務を意識しながら「このコードはここに書くべきなかな？」というのを探求しながらコードがかけるとだんだんと変更に強いコードがかけるようになってきます。