MVCを理解してコードを書く②MVC+Sについて
昨日はMVCについて解説を書きました。
今日はそこに＋Sの日です！！！！
復習:MVC
| 役割 | 説明 |
|---|---|
| Model | アプリケーションのデータやビジネスロジックを管理し、 ViewやControllerに対して通知を送信。 アプリケーションのデータの中心となるコンポーネント |
| View | ユーザーが操作するインターフェースを提供し、Modelから受信したデータを表示する。 |
| Controller | モデルとビューを仲介するコンポーネント。 アプリケーションの振る舞いを制御するコンポーネント |
Skinny Controllers, Fat Models, Simple Views.
MVCモデルの特徴は、アプリケーションの内部データと処理を分離し、
各コンポーネントの役割を分けて管理しているため、
(各コンポーネントが疎結合になり、変更や拡張に柔軟に対応できるため)
保守性と拡張性の向上になっていること。
MVC+SのSってなんだ？
MVC+SにおけるS ＝ "Service"（サービス）
- MVC+Sは、MVC（Model-View-Controller）アーキテクチャに、
Service層を追加したソフトウェアデザインパターン。
MVC+SのSができた理由はなんだ？
- MVC+SのSができた理由は、
MVCアーキテクチャがアプリケーションの基本構造を提供する一方で、
複雑なビジネスロジックを実装することができないことが明らかになったため。
アプリケーションの複雑性に対処する必要性から生まれたためにServiceができた。
ここでいう「アプリケーションが複雑になる」とは:
アプリケーションの機能やデータの種類が増え、ビジネスロジックが複雑になることを指す。
"MVCアーキテクチャは、アプリケーションのビュー、モデル、コントローラの責任を分離することによって、アプリケーションの保守性、拡張性、テスト容易性を向上させることができるようになっている"
と、前回で説明した。
しかし、アプリケーションが複雑になると、
ビジネスロジックをモデルに直接実装することが難しくなる。
ビジネスロジックが複数のモデル間で共有されたり、複数のデータソースからのデータを処理する必要があるからだ。
例を出すと。。。
ECサイトでの商品注文の処理を考えてみる。
注文処理には以下のような一連の流れがあります。
- カートに商品を追加する
- 注文情報を入力する
- 在庫数を減らし、注文履歴を保存する
- 顧客にメールで注文確認メッセージを送信する
このような場合、ビジネスロジックをモデルに直接実装することは困難だ。
なぜなら、複数のモデルにまたがって処理が行われるためです。
- 在庫数を減らす => 商品情報と在庫情報の両方を参照する必要がある。
- 注文履歴を保存する => 注文情報と顧客情報の両方を参照する必要がある。
- 顧客にメールで注文確認メッセージを送信する
=> 注文情報と顧客情報を参照し、メールサーバーとの通信も必要。
ビジネスロジックをService層に実装することで、複数のモデルを連携させることができる！ということ
そこで、Service層が導入された！！！
Service層は、アプリケーションのビジネスロジックを実装するための仲介役として機能し、
コントローラとモデルの間でデータをやりとりするためのメソッドを提供する。
これにより、ビジネスロジックがモデルから分離され、より洗練された、
独立したアプリケーションを作成することができるようになった。
Serviceって？
- Service層は、アプリケーションのビジネスロジックを実装するために使用される。
-
コントローラとモデルの間で仲介役として機能し、モデルの状態を変更するためのメソッドを提供する。
これにより、アプリケーションのロジックをモデルから分離し、より洗練された、
独立したアプリケーションを作成することができる。
Service層は、上記の発生した理由から見て分かる通り、
一般的にビジネスロジックが複雑で、モデルに直接実装することが難しい場合に使用される。
ex. )複数のモデル間でのデータのやり取りや、複数のデータソースからのデータの取得など
Discussion