MVVMアーキテクチャパターンは、ソフトウェア設計においてよく使われるパターンです。主に3つの要素から構成されています。
Model
- アプリケーションのデータを表現する部分
- データベースからデータを取得したり、APIからデータを取得したりする役割があります
- モデルクラスはビューやコントローラーから直接参照されることはありません
View
- ユーザーインターフェイスを表す部分
- モデルのデータを表示する役割があります
- ユーザーの入力を受け取り、ビューモデルに通知する役割もあります
ViewModel
- ビューとモデルの間の橋渡し役となる部分
- ビューからのイベントを処理し、モデルのデータを適切に加工してビューに渡します
- モデルのデータが変更された場合、ビューに変更を通知する役割もあります
具体例を挙げると、タスク管理アプリでは以下のようになります。
Model
- Task: タスクのデータ(タイトル、説明、期限など)を保持するクラス
- TaskRepository: データベースやAPIからタスクデータを取得、保存するための機能を持つクラス
View
- TaskListView: タスクの一覧を表示するUIの部分
- TaskDetailView: 選択したタスクの詳細を表示するUIの部分
ViewModel
- TaskListViewModel: タスク一覧を管理し、TaskListViewに渡すデータを用意する
- TaskDetailViewModel: 選択したタスクの詳細データを管理し、TaskDetailViewに渡すデータを用意する
ユーザーがTaskListViewでタスクを選択すると、TaskListViewModelがTaskRepositoryからデータを取得し、TaskDetailViewModelにデータを渡します。TaskDetailViewModelはデータを加工し、TaskDetailViewに渡して表示させます。
新しいタスクを追加する場合は、TaskDetailViewModelが新しいTaskインスタンスを作成し、TaskRepositoryに保存を指示します。
このように、MVVMパターンを使うことで、UIロジックとビジネスロジック、データアクセスロジックを分離でき、保守性が高く拡張性のあるアプリケーションを構築できます。
補足説明
MVVMパターンにおける役割分担を日常の例えで説明すると以下のようになります。
Model
- 材料そのもの(生地、野菜、肉など)に当たります
- 自分で育てたり、市場から仕入れたりするところがデータ取得にあたります
View
- 実際に盛り付けられた料理の状態そのものを指します
- 見た目はこうなっているが、具体的な調理方法は分からない
ViewModel
- 料理人の役割に相当します
- 材料を見て、どう料理を作るかを指示します
- 盛り付けの指示もしてView(料理の出来上がり)に反映されます
- 材料が追加で必要になれば、Model(材料)に指示を出します
つまり、MVVMはUI部分(View)とデータ部分(Model)を分離し、両者を仲介するViewModel(料理人)が存在することで役割分担ができ、変更があった際の影響範囲を最小限に抑えられるようになっています。
一般的なアプリの例でいうと、
- Model = データベースやAPIからのデータ
- View = 画面UIそのもの
- ViewModel = 画面の動作ロジックとUIロジックを担当
というように整理できます。三者の役割を分けることで、保守性と拡張性が高いアプリケーションを実現できるのがMVVMパターンの利点です。
