MVCとservice,Repojitoryについて改めて振り返る

MVCとservice,Repojitoryについて改めて振り返る

今までRailsを触ることが多かったですが、最近はSpringを触っていたので、
再度MVCについて振り返りつつ、使ってこなかったservice,Repojitoryについてもまとめてみました。

MVC（Model-View-Controller）アーキテクチャ

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

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

用語説明: 保守性と拡張性

保守性とは:

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

拡張性とは:

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

MVCアーキテクチャの特徴

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

なぜ分離することで、保守性や拡張性が向上に？？

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

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

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

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

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

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

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

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

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

MVC:それぞれの役割

Model

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

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

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

Railsにおいてはこのように、モデルにもロジックをかくが、
javaを使用した大規模アプリケーションの作成時には、ビジネスロジック関連はServiseに書く。

View

• ユーザーに表示されるUI（ユーザーインターフェース）を担当するコンポーネント。

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

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

Controller（コントローラ）

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

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

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

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

MVC + Service

• MVC+SのSができた理由は、
  MVCアーキテクチャがアプリケーションの基本構造を提供する一方で、
  複雑なビジネスロジックを実装することができないことが明らかになったため。
  アプリケーションの複雑性に対処する必要性から生まれたためにServiceができた。

ここでいう「アプリケーションが複雑になる」とは:
アプリケーションの機能やデータの種類が増え、ビジネスロジックが複雑になることを指す。

"MVCアーキテクチャは、アプリケーションのビュー、モデル、コントローラの責任を分離することによって、
アプリケーションの保守性、拡張性、テスト容易性を向上させることができるようになっている"

と、前回で説明した。

しかし、アプリケーションが複雑になると、
ビジネスロジックをモデルに直接実装することが難しくなる。
ビジネスロジックが複数のモデル間で共有されたり、複数のデータソースからのデータを
処理する必要があるからだ。

Serviceの使用

Serviceは、アプリケーションのビジネスロジックをカプセル化したコンポーネントです。
アプリケーションのビジネスロジックを実装するために使用される。

コントローラとモデルの間で仲介役として機能し、モデルの状態を変更するためのメソッドを提供する。

Serviceは、モデル（データ）に対する操作やビジネスルールの実装、複数のモデル間での
処理の調整などを担当。
Serviceは、コントローラから呼び出され、必要なデータの取得や更新、処理の実行などを行う。

MVC + Repository：　Repositoryの役目

Repositoryパターンは、
データベースや永続的なデータストレージに対するアクセスを抽象化するために使用される。

データベースやファイルシステムなどのデータストアにアクセスし、データの作成、読み取り、更新、削除（CRUD操作）を実行するメソッドを提供する。

MVCパターンにおいて、Repositoryはモデル（データ）との間のインターフェースとして機能する。
コントローラはRepositoryを介してデータを読み書きし、必要なデータを取得してビューに提供。
これにより、ビジネスロジック（コントローラ）とデータの永続性（Repository）が疎結合になり、
コードの保守性やテスト容易性が向上する。

Repositoryの役割は、
データの永続性を担当し、データストアとのやり取りを抽象化してアプリケーションの他のコンポーネントとの間のインターフェースを提供すること！

---

もっとserviceとRepository、勉強します！