none
MVVMでCanvasを使用して図形の移動や拡大縮小を実装する方法 RRS feed

  • 質問

  • MVVMでCanvasを使用して図形の移動や拡大縮小の動作を検討しています。

    以下の記事を参考にして、一通り動作しました。

    https://social.msdn.microsoft.com/Forums/ja-JP/b43f2db9-b985-47e5-a00a-f69b432993cf/mvvm12391view12395usercontrol12398collection124343492031034123731237912427?forum=wpfja


    悩んでいる内容は下記の点です。

    ・図形の移動や拡大・縮小は誰の責務になるのか。

    ①MouseMoveなどをコマンドで投げて、ViewModelかModelで実装する場合、
    ViewModelかModelの責務かはどのようにして決定しますか?


    ②ItemsControlをカスタマイズしたコントロールを自作して移動や拡大縮小の動作をViewに閉じ込めて、
    バインドするだけでViewModelとやりとりはできるのでしょうか?


    現状、①で実装をしていますが、ViewModelでもModelでも動作自体は実装できるため、悩んでいます。

    よろしくお願いします。


    • 編集済み Y...M 2020年2月4日 0:47
    2020年2月4日 0:42

回答

  • Modelはあくまでもデータの部分、ViewModelはViewから受けた値を処理し、時に加工した結果をModelに渡す役割を行うのが一般的だと思います。
    また、ModelとViewModelで一つずつのクラスだけがあるのではなく、それぞれの役割を担うユーティリティ的なクラスも存在することが多く、これらを含めると概念的にどこまでがModelでどこまでがViewModelというのを一意に決めるのは難しくなると思います。
    よって、クラスで見た時のModelとViewModelと、概念で見た時のModelとViewModelでは違いがあるということです。

    ちなみに私の場合は、データを入れるクラス、それらデータをViewにバインドしやすいようにしたクラス、これらをコレクションとして扱うクラス、これらのエラーチェックを行うクラスでModelという概念を実現しています。クラスとして言えば、最初に書いた「データを入れるクラス」がModelに相当すると思います。


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    • 回答としてマーク Y...M 2020年2月4日 5:43
    2020年2月4日 3:11
    モデレータ

すべての返信

  • Modelはあくまでもデータの部分、ViewModelはViewから受けた値を処理し、時に加工した結果をModelに渡す役割を行うのが一般的だと思います。
    また、ModelとViewModelで一つずつのクラスだけがあるのではなく、それぞれの役割を担うユーティリティ的なクラスも存在することが多く、これらを含めると概念的にどこまでがModelでどこまでがViewModelというのを一意に決めるのは難しくなると思います。
    よって、クラスで見た時のModelとViewModelと、概念で見た時のModelとViewModelでは違いがあるということです。

    ちなみに私の場合は、データを入れるクラス、それらデータをViewにバインドしやすいようにしたクラス、これらをコレクションとして扱うクラス、これらのエラーチェックを行うクラスでModelという概念を実現しています。クラスとして言えば、最初に書いた「データを入れるクラス」がModelに相当すると思います。


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    • 回答としてマーク Y...M 2020年2月4日 5:43
    2020年2月4日 3:11
    モデレータ
  • 回答ありがとうございます。

    それぞれの役割を担うユーティリティ的なクラスも存在することが多く、

    このユーティリティにCanvasの振る舞いを実装するような理解をしましたが、

    このCanvasの振る舞いはViewModelでしょうか?

    それとも、Model内のプレゼンテーションよりのレイヤにあるものでしょうか?

    MVVMのViewとModelの分離というものを解釈するとViewModelなのでしょうか。

    ケースバイケースかと思いますが、例をご教示いただければ幸いです。

    よろしくお願いします。

    2020年2月4日 5:01
  • MVVMデザインパターンは、そのように組めば組みやすく、保守もしやすく、Viewと分離できるのでViewと整合性が取りやすいなどのメリットがあります。その方向性を実現するためのものであって、どのようなクラス構成になっているのかを明確に定めたものではありません。デザインパターンとしては一定のものがありますが、現実のコーディングとなると必ずしもそれにきっちり当てはまるものではありませんし、当てはめる必要もありません。あくまで、概念として捉えた方がよろしいかと思います。

    例えば、Modelを実際にViewにバインドするのは無理があります。数値項目であれば数字しか入らなくなってしまうなどの弊害があるからです。よくDataTableはレガシーで使いにくいと言っている人がいますが、それはDataTableはバインドするために設計されているわけではないからです。DataTableは主にデータベースとのやり取りのために設計されています。
    話を戻して、よって、私はViewとバインドするためのクラスを別途用意します。これはViewModelとModelの橋渡しでもあります。このクラスはViewModelでしょうか? Modelでしょうか? 私はどちらか一方的ではなく、それらの中間的なクラスだと思います。
    つまり、概念的にはMVVMは実現できているが、それを構成するクラス群は、それぞれ明確にView, ViewModel, Modelのグループに分けることができません。
    大切なことはMVVMの概念を実現することであって、クラスをMVVMに明確に分離する作業ではないと思います。


    ★良い回答には質問者は回答済みマークを、閲覧者は投票を!

    2020年2月4日 5:32
    モデレータ