読者です 読者をやめる 読者になる 読者になる

しっぽを追いかけて

ぐるぐるしながら考えています

Unity と猫の話題が中心   掲載内容は個人の私見であり、所属組織の見解ではありません

JXUGC #2 東日本編のセッションの補足

先日の JXUGC 第二回 東日本編でのセッション資料は下記に公開していますので共有します!

Xamarin で Prism を使いたい! ~「正式対応」 まで待てない人のための Prism 利用 Tips~

それとセッション後に某先輩に「Prism 推しの説明なさすぎ!」などごもっともなご意見をいただいたので、なぜ Prism 推しなのかを、今さらながら補足しておきます・・・

Prism 押しの理由、それは今普及している「MvvmCross」より「Prism + Unity」の方が将来性がありそうだと感じているからにつきます

どんなところかひと言で表現するなら

  • MvvmCross

    • 設計による抽象化よりも実装コード量削減重視
    • 暗黙的規則や各プラットフォーム個別実装が多い
  • Prism + Unity

    • 実装コード量削減よりも設計による抽象化重視
    • Xamarin 未対応だが拡張性・保守性がより高い印象

という感じでしょうか

例えば具体的にどんなところかというと

f:id:matatabi_ux:20141124201248p:plain

例えば画面における View と ViewModel の関係について

どちらも View が ViewModel を参照していますが、MvvmCross は ViewModel が View を指定する形で関連付けするのに対し、Prism では View が ViewModel を指定する形で関連付けします

画面についてだけの関係で、各コントロールは ViewModel を個別に選択・バインドできるので問題ないのかもしれませんが、本来 ViewModel はどの View から参照・バインディングされてもよいように画面の状態を抽象化してデータとして保持する役割を持っているはずです

MvvmCross のように ViewModel が View を指定する方式は「Page と PageViewModel は1:1対応」のような暗黙的規則を強制することで実装コード量を削減する利点はあると思います

ただ、暗黙的規則を崩そうとすると、とたんに複雑なるので拡張性は少し下がると思うのです

こういった懸念は、他にも MvvmCross の下記のような点に感じます

  • アプリケーション基底クラスに DI コンテナの機能が埋め込まれている
  • DI コンテナに登録すると必ず Singleton になる
  • 画面は個別だが ViewModel は共有 (特定プラットフォーム専用データが共通コードに入る)
  • Xamarin.Forms による UI の共通化にはどうも進んでいかなそう

現状では Xamarin で MVVM を導入する上での最適解ではあると思うのですが、今後 IoT やウェアラブルデバイスなど対応すべきプラットフォームが増えたり、もっと実装を抽象化して共通部分を増やす設計を導入したいと思ったときに MvvmCross より Prism + Unity の方がやりやすいのではないでしょうか

Prism の方が理解して使いこなすのは難しいですし、Xamarin 対応もまだですが、あえて Prism 推しなのは上記のような理由によります

だいぶ長くなってしまいましたが、セッションについての補足でした!