この記事は東京海洋大学NePPの Advent Calendar 2024の3日目です。
はじめに
この記事は、自身がRuby on RailsにてMVCモデルについて学んだことと＋αをアウトプットの機会としてを書きました。
あくまで個人的な見解ですので、あしからずご容赦ください。
MVCモデルとは？
まずMVCってなんだよってところからですが、
MVCモデルは、ソフトウェアの設計パターンの一つで、特にWebアプリケーション開発で広く使われています。一般的なアーキテクチャの一つです。
MVCは以下の3つのコンポーネントから構成されます：
・Model（モデル）
・View（ビュー）
・Controller（コントローラー）
それぞれが異なる役割を持ち、アプリケーションの機能を分割して扱いやすくしています。
Canvaで簡単に図式化してみました。
Model（モデル）
・データとビジネスロジックを管理する部分。
・データベースとやり取りし、アプリケーション内でのデータを扱う。
・データのバリデーションを管理する部分。
お気持ちとしては、「データを正しく管理するお仕事」
class User < ApplicationRecord
validates :name, presence: true
end
View（ビュー）
・ユーザーに表示する部分（UI部分）。
・HTMLやCSS、JavaScriptなどを使い、データを視覚的に表現する。
・コントローラーから渡されたデータを受け取り、Webページとして表示する。
お気持ちとしては「どんなデータかは知らないけど、モデルとコントローラーから渡されたデータをユーザーに表示するのがお仕事」
<h1>Welcome, <%= @user.name %>!</h1>
Controller（コントローラー）
ユーザーのリクエストを処理し、適切なモデルやビューを呼び出す。
例えば、URLに対応するアクションを実行し、モデルを利用してデータを取得し、ビューに渡す。
class UsersController < ApplicationController
def show
@user = User.find(params[:id])
end
end
お気持ちとしては、「ユーザーからリクエストが来たら、最初に対応する場所で、『このデータが欲しい』とか『この情報を送信したい』って頼まれたら、Modelからデータを取ってくるという、モデルとViewの架け橋的存在」
サービスクラス
サービスクラスの目的とメリット↓
役割の分離
コントローラーはリクエストとレスポンスの管理に専念し、サービスクラスにビジネスロジックを委託します。コントローラーの肥大化を避けることに使われます。
モデルはデータベースとのやり取りやバリデーションに集中し、複雑なロジックを避けることができます。
コードの再利用性
サービスクラスに切り出すことで、同じロジックを複数のコントローラーやモデルから呼び出せます。
テストのしやすさ
ビジネスロジックを独立させることで、サービスクラス単体でテストを行いやすくなります。
これらは、Ruby on Rails のDRY原則にも当てはまりますね。👀
インターン先では、ビジネスロジックはコントローラーには書かず全てサービスクラスに書くように言われましたが、場面によってはアンチパターンになることもあるそうです。
おわり
この記事がこれからMVCモデルについて学ぶ方の少しでも手助けになればと思います！
参考