🦁

MVCを理解してコードを書く:"Skinny Controllers, Fat Models, Simple Views."

2023/04/26に公開

MVC(Model-View-Controller)アーキテクチャについて

MVCはアプリケーション設計パターンの一つであり、
アプリケーションの構造や機能を整理するために使われます。
Model(モデル)、View(ビュー)、Controller(コントローラ)の略語で、それぞれが異なる役割を持ちます。

MVCの仕組みと役割を理解してコードを書けることで、
アプリケーションのコードを役割ごとに分けることができ、保守性と拡張性が向上します。

今日はここを詳しくやっていきます。

RailsにおけるMVCアーキテクチャ

  • Railsは、MVC(Model-View-Controller)アーキテクチャに基づいて
    設計されているWebフレームワーク

    プログラミング言語Rubyで記述されたオープンソースのフレームワーク!
  • MVCは、アプリケーションを3つの役割に分割し、
    それぞれの役割に対応するコンポーネントを定義する

  • MVCはソフトウェア内部のデータと処理を、
    ユーザーから分離することで、ソフトウェアの保守性や拡張性を向上させる
    考え方でもある。
  • アーキテクチャ
    ソフトウェアやコンピュータシステムを設計する際に用いられる、構造や機能、役割などを定義する基本的な枠組みのこと。
    システムを構成するコンポーネントやモジュール、その関係性や相互作用を定義することで、
    システムの設計や開発、保守などを支援している。
  • コンポーネント
    ソフトウェア開発において、再利用性を高めるために独立して設計・実装された単位部品のこと。

MVCアーキテクチャの特徴

1. データと処理の分離:
アプリケーション内部のデータと処理をモデルとして分離することで、保守性や拡張性が向上する。

なぜ分離することで、保守性や拡張性が向上に??
  • データの一元管理ができる
    モデルにデータをまとめて管理することで、同じデータを複数の場所で使い回すことができ、
    データの一元管理が可能になり、データの整合性や一貫性が保たれ、保守性の向上になる。

  • 機能の追加や変更の容易性
    モデルに処理をまとめて実装することで、機能の追加や変更が容易になる。
    = 変更に伴う影響範囲が小さくなり、保守性が向上する。

  • システム全体の見通しの向上:
    モデルがデータや処理をまとめることで、システム全体の見通しが良くなる。
    モデルが担当する範囲が明確になるため、他のコンポーネントとの依存関係が少なくなり、
    システム全体の設計がしやすくなる。

2. 役割の分離:
アプリケーションをモデル、ビュー、コントローラの3つの部分に分割し、
それぞれの役割を明確に定義する。
=> 下記項目に詳細を掲載

3. 疎結合:
ViewやControllerからModelに直接アクセスすることができず、
全てのやりとりはControllerを通じて行う
これにより、ViewやControllerとModelを疎結合に保つことができ、保守性や拡張性が向上する。

疎結合: ソフトウェアのコンポーネント間の依存度を低く保つこと

4. 再利用性:
同じModelを使って複数のViewやControllerを作成することができるため、再利用性が高くなる。

5. テストのしやすさ:
各部分の役割が明確に分かれているため、単体テストや結合テストがしやすくなる。

6. 開発効率の向上:
上記した役割の分離や再利用性の高さにより、開発効率が向上します。

補足:保守性と拡張性

保守性とは:

ソフトウェアが正しく動作するために必要な修正や改善を行うための容易さを示す指標
保守性が高いソフトウェアは、変更に強く、バグの修正や新しい機能の追加などが容易に行える。

拡張性とは:

ソフトウェアに新しい機能を追加するための容易さを示す指標
拡張性が高いソフトウェアは、新しい要件に応じて容易に機能を追加でき、変化に柔軟に対応できる。


MVC: 役割の分離-それぞれの役割について

Model

  • データやそのデータに関する処理を担当するコンポーネント。
    アプリケーションが扱うデータやデータ処理を担当する部分。
    => アプリケーションのデータの中心となるコンポーネントで、アプリケーションにおけるデータのやり取りを担当する。

  • モデルは、データベースやファイル、外部APIなどからデータを取得し、そのデータを操作するためのメソッドを提供。ビジネスロジックやデータのバリデーションなども、モデルに含まれる。

  • 言葉を変えると、
    取り扱うデータの構造(≒ DDDにおけるドメインモデル)と、それに紐づくビジネスロジックを管理するとも言えます。

View

  • ユーザーに表示されるUI(ユーザーインターフェース)を担当するコンポーネント
  • ビューは、HTML、CSS、JavaScriptなどを使用して、ユーザーがアプリケーションを操作するためのインターフェースを提供。
    モデルから取得したデータを表示するために使用され、ユーザーが入力したデータをコントローラに渡すためのフォームなども提供する。

Controller(コントローラ)

  • モデルとビューを仲介するコンポーネント

  • ビューとモデルの媒介を行い、
    必要に応じて横断的なアプリケーションのビジネスロジックの呼び出しを定義する。

  • コントローラは、ユーザーのリクエストを受け取り、適切なモデルのメソッドを呼び出してデータを取得、それをビューに渡して表示する。
    また、ユーザーが入力したデータを受け取り、それをモデルに渡して処理させる。

コントローラは、アプリケーションの振る舞いを制御するコンポーネントであり、ルーティングやセッション管理なども担当しする

この役割を理解してコードを書くことが大事です。

Skinny Controllers, Fat Models, Simple Views.

上記項目では、MVCのそれぞれの役割が理解できたと思うが、
これは各要素の責務を表現するためのキーワードだ。

Skinny Controllers

  • コントローラーができるだけシンプルに保つこと。
    上記の通り、ModelとViewの橋渡しや、指示が役目だ。
    コントローラーはHTTPリクエストを受け取り、必要なデータをモデルから取得し、
    ビューに渡すことが主な役割。

  • ビジネスロジックなどの複雑な処理はモデルに任せ、コントローラーはその処理に関与しないようにすることが望ましいとされている。

Fat Models

モデルが責務を担うことが多いという意味
モデルは、データベースからデータを取得したり、データを操作したりするなど、
ビジネスロジックの大部分を担当
また、ビジネスロジックを共通化したり、再利用可能なコードを作成することも重要な役割だ。

Simple Views

  • ビューができるだけ単純に保つことを意味する。
    ビューは、コントローラーから渡されたデータを受け取って、ユーザーに表示する役割を持つ。

  • ビューが複雑になりすぎると、メンテナンスやテストが難しくなるため、
    シンプルな構成にすることが望ましい
    とされている。

これらの原則に従うことで、MVCアプリケーションの保守性や拡張性を高めることができる!!!!!

リファクタリング例としてはこの方のページがわかりやすく書かれています。
https://qiita.com/nashirox/items/edf5e8e9e7b8fc6891d3

MVC + Sについて

ここについて次回は解説していきます。


参考

https://olegkrivtsov.github.io/using-zend-framework-3-book/html/en/Model_View_Controller/Skinny_Controllers__Fat_Models__Simple_Views.html

https://developer.mozilla.org/en-US/docs/Glossary/MVC

Discussion