334
Help us understand the problem. What are the problem?

posted at

updated at

MVVMを勉強するときに参考になった 概要まとめ & アンチパターン & リンク集

MVVMについて勉強したことのまとめ

今更ながら、MVVMな開発をお仕事で行なっています。
全然理解できていないので、色々と調べつつメモを残していきます。

また、こんな実装はMVVMじゃない?ってきなことも今後の反面教師になるように記載してみました。

MVVM

  • プログラムを3つの要素、Model、View、ViewModel に分割
  • 各要素は、単方向に依存している View -> ViewModel -> Model
  • MVVMは、あくまでUI周り構成について触れているだけであって、Modelの中身については、各自で考える必要がある

View

  • ViewModelの情報を使用してUIを描画 = binding
  • ViewModelにアクションを送信 = commands

ViewModel

  • UIに描画するのに必要な情報を準備、保持 = Modelを保持?
  • Viewから送られたアクションをModelに通知
  • Modelから、UIの描画に必要な情報に変換保持

Model

  • ViewとViewModelがやること以外全て受け持つ
  • つまり、データ本体、加工、取得、保存などは、VMで行わず全てMdoelが受け持つ

こんな実装はMVVMじゃない?

Viewの場合

  • ViewがVMのプロパティを直接操作している
  • ViewがアクションをVMに送るときに、コールバッグ(blockやobservable)を実行する
  • ViewがViewModelから受け取る描画内容変更処理内で、新たにVMの操作をしている
  • View内でViewModelを差し替えることができない
    また、ViewModelを差し替えたときにUIが元の状態に戻らない
  • DataBindingを使ってない
     DataBindingを使わないと、MVPのPresenterをViewModelと言っているだけな気がしてます。(人によって解釈が変わるみたいなので、正しくはどうなんでしょうか・・)

ViewModelの場合

  • ViewModelがModelのプロパティを直接操作している。なるべく、アクションとして通知、操作する
  • Viewを知っている
  • ViewModel内でModelを差し替えることができない
    また、Modelを差し替えたときにUIが元の状態に戻らない
  • Modelの情報をViewに通知する以外の機能を実装している = ビジネスロジックが実装されている

Modelの場合

  • View・ViewModelを知っている

MVVMと一緒に紹介されるVIPERについて(主にiOS用)

VIPERは、以下の頭文字から命名されていて

  • View
  • Interactorinteractor(Model)
  • Presenter
  • Entity
  • Rotuer

Entity以外は全てProtocolに準拠して実装するので、全体的に疎結合にできるアーキのようです。
Clean ArchitectureをiOSに適用したものって感じのようです。

MVPの不明瞭な画面遷移周り規約がある感じのアーキテクチャですが、
Presenter <=> View 部分に、DataBindingを用いることで、MVVMにも使用できると思います。

MVVMについて参考になったorなりそうなリンク集

Wikipedia

記事

技術ブログ

スライド

iOS実装例など

Register as a new user and use Qiita more conveniently

  1. You can follow users and tags
  2. you can stock useful information
  3. You can make editorial suggestions for articles
What you can do with signing up
334
Help us understand the problem. What are the problem?