■ はじめに
説明
先日ふと個人開発しようと思い、技術要件だったり実装する機能だったりをまとめていました。
そんな中、「アーキテクチャどうしよう。そもそも MVC 以外よく知らないや」という状況だったんで MVVM（クリーンアーキテクチャはまた今度）について調べて自分の言葉でまとめてみました。
過不足あれば是非ご指摘ください！
■ MVVM (Model View ViewModel) とは
ソフトウェアアーキテクチャの一つであり、アプリケーションの設計パターンの一つです。
- Model：
- 【役割】データやビジネスロジックを管理する。
- 【説明】ユーザーの情報やアプリケーション全体のデータを保持し、ビジネスロジックを実行する。
- 【例】 例えば、タスク管理アプリの場合、ユーザーが作成したタスクのリストやその状態（完了しているかどうか）を管理する。新しいタスクを追加したり、タスクの完了状態を更新したりする処理もここで行う。
- View：
- 【役割】ユーザーインターフェース（UI）を構築し、ユーザーの操作を受け付ける。
- 【説明】画面上にボタンやテキストフィールドなどの UI 部品を画面に配置し、ユーザーがそれらを操作する。
- 【例】タスク管理アプリの場合、画面上にタスクの一覧や新規タスクの入力フィールドを表示する。ユーザーはここでタスクを追加したり、完了したタスクをチェックすることができる。
- ViewModel：
- 【役割】View と Model の間でデータのやり取りを行い、ビジネスロジックを処理する。
- 【説明】View から受け取ったデータを整形し、Model に送る。また、Model の変更を View に通知して UI を更新する。ビジネスロジックの実装やデータの整形を担当する。
- 【例】View から新しいタスクの入力を受け取ってそれを適切なデータ構造に変換し Model に渡す。タスクが完了した際にはその情報を View に反映させて UI を更新する。
タスクアプリで MVVM を採用した場合、どういう流れになるのかを考えてみる。
- 【View（ユーザー）】アプリを操作し、タスクAを追加する。
- 【View（ViewModelへの通知）】View はタスクAの追加を ViewModel に通知する。
- 【ViewModel】View から受け取ったタスクAの情報を適切なデータ構造に整形し、Model に渡す。
- 【Model】ViewModel から受け取ったデータ（タスクA）を実際にデータベースやストレージに追加する。
- 【ViewModel】View に必要な更新を通知する。
- 【View】ViewModel からタスクAが追加された通知を受け取り、必要に応じて UI を更新して、ユーザーに新しいタスクが追加されたことを表示する。
メリット
- 運用・メンテナンスの向上
- ロジック（Model）とUI（View）を分離することで、コードの可読性と再利用性が向上。
-
単体テストのしやすさ
- ViewModel は UI に依存しないため、単体テストがやりやすい。
-
データバインディング
- View / View Model どちらかの値（データ）が変わると、自動的にもう片方も変更される。なので、2回の変更が必要なくなり1回で済む。手間が減るのはもちろんのこと、あっちはAなのにこっちはBみたいな不整合が起きない。
デメリット
- ViewModel の負担増加
- ViewModel に多くの責任が集中し、複雑化する可能性がある。
- 過剰設計
- プロジェクトが小さい（ミニマムな個人開発レベル）場合、MVVMの導入が過剰設計となり、逆に負担になることがある。
この場合、MVCの方が適しているかも？（個人の見解）
- プロジェクトが小さい（ミニマムな個人開発レベル）場合、MVVMの導入が過剰設計となり、逆に負担になることがある。
ディレクトリ構造
ディレクトリ構造としては下記のような感じ。
JavaScript のライブラリである mermaid というもので作成。
各フォルダを作り、その配下にファイルを作成する。
（Flutter のプロジェクトなので拡張子が dart だが、ここは気にしなくて大丈夫です）
以上。
■ 参考文献