view と viewmodel どっちで処理するか

Question

WPF でアプリ作ってると、この処理 view でやるのか viewmodel でやるのかどっちでやるのか迷うことがあります。
特に、別ウィンドウを開く、メッセージダイアログ、ファイルダイアログ、印刷、などの Windows 的なところに触れるもの。

データがほぼ viewmodel にあるので出来る限り viewmodel でやりたいのですが、ときどきコントロールのプロパティが get のみで Binding もできないようになっていて、 viewmodel にデータを持ってくるのが難しいことがあります。
それを取得するために view を viewmodel で持ったり、 view が viewmodel のプロパティにラムダ式代入したりすることになります。

逆にそれらを view でやろうとすると、こちらも引数に渡したいデータは viewmodel にしかなく、 DataContext から直接プロパティ見たりメソッド呼んで取得することになります。

どう書いても綺麗にいかないなー と思ってるのですが、楽にするためにこういう機能ある、とか こうすればいいとかありましたら教えてほしいです。

Answer 1

ViewとかViewModelとか呼んでいるからには、MVVMを前提としていると解釈してよろしいですか？
であれば、ViewとViewModelは疎結合にすべきであって、ViewがViewModelの型を知っていたり、ViewModelがViewを直接参照したりは極力避けるべきであるというのが僕の考えです。

ViewModelがダイアログや別のウィンドウを生成するというのも個人的には好きじゃないです。
Viewのコードビハインド（xaml.cs）を書きたがらない人もいるでしょうが、Viewを作るのはViewが担当するのが一番自然だと思います。

さて、実現方法ですが、ViewModelからViewへの必要な情報の受け渡し自体は、
View側に依存関係プロパティを作ってやって、そこにバインドすることで解決すると思います。

ViewModelを処理の起点としてViewを操作したいときも、同様にプロパティの値変更をトリガとする方法があります。
例として、ViewModelのプロパティ変更をトリガとして別ウィンドウを表示する場合、以下のようになります。

public partial class MainWindow : Window
{
    //子ウィンドウのDataContextプロパティ
    //（型をViewが知る必要はないのでobject）
    public object AWindowContext
    {
        get { return (object)GetValue(AWindowContextProperty); }
        set { SetValue(AWindowContextProperty, value); }
    }

    public static readonly DependencyProperty AWindowContextProperty =
        DependencyProperty.Register("AWindowContext", typeof(object), typeof(MainWindow),
                                    new PropertyMetadata(null, OnAWindowContextChanged));

    private static void OnAWindowContextChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        var me = d as MainWindow;

        //プロパティに新しいオブジェクトが設定されたのをトリガに
        //そのオブジェクトをDataContextとして子ウィンドウを表示する
        if (me.AWindowContext != null)
        {
            var wnd = new AWindow();
            wnd.Owner = me;
            wnd.DataContext = me.AWindowContext;

            wnd.ShowDialog();
        }
    }

    //コンストラクタ
    public MainWindow()
    {
        InitializeComponent();

        //Binding設定
        SetBinding(AWindowContextProperty, "AContext");
    }
}

public class MainWindowViewModel : INotifyPropertyChanged
{
    private AWindowContext _aContext;

    //ウィンドウを表示したいときはここにオブジェクトをセットする
    public AWindowContext AContext
    {
        get
        {
            return _aContext;
        }
        private set
        {
            if (ReferenceEquals(_aContext, value)) return;
            _aContext = value;

            //更新通知
            var h = PropertyChanged;
            if (h != null) h(this, new PropertyChangedEventArgs("AContext"));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

何かMVVM支援のフレームワークを使われているのであれば、添付ビヘイビアの仕組みを使うともう少し楽に書けると思います。

---

別の方法としては（これもMVVMフレームワーク使用が前提になると思いますが）メッセンジャーパターンというのがあります。
これは、ViewModelからViewへの依頼内容をMessegeオブジェクトにパッケージングして、Messengerクラスに通達を依頼する実装パターンです。

これについては↓このあたりがわかりやすいかと思います。
http://tnakamura.hatenablog.com/entry/20110218/mvvm_messenger

Comments

[lazex]

依存プロパティはユーザコントロールでしか使ってませんでしたが、Windowが自分のVMに対しても使うのですね
.netの機能だけを使うとただWindow開くだけでかなり長くなっていますが、例えばVMからウィンドウを閉じたいというのであれば、AWindow～のところをクローズ用に同じようなものをもうひとつとなるのでしょうか？

[lazex]

もう一点質問ですが、現在の私の方法が kiichi54321 さんの解答にある
> http://sourcechord.hatenablog.com/entry/2016/01/23/170753
これに近いです。
（ダイアログはViewModelで直接のときもある）
クラスではなく、返して欲しい型だけを指定したラムダ式ですけど。

これだと疎結合ではなく ViewModel の型を知ってることになりますが、このURLの方法よりも疎結合にしたほうが良いメリットはどういうことがありますでしょうか？

疎結合が良いという話は聞きますが、私の中ではViewとModelは全く依存しない疎結合でいいと思うのですが、ViewとViewModelは名前からしても関連しているものでView専用のデータ処理（setterで個々が変わるとアレ変えてコレ変えてみたいな）をするところなのでそこまで疎結合にする必要はあるのかと疑問に思っています。

[oika]

>.netの機能だけを使うとただWindow開くだけでかなり長くなっていますが、例えばVMからウィンドウを閉じたいというのであれば、AWindow～のところをクローズ用に同じようなものをもうひとつとなるのでしょうか？

同じ方法でやるならば、そうなるでしょうね。モーダルに開いている場合はどちらかというとAWindowContextのほうに作ることになるかと思いますが。
支援ライブラリを使わずにMVVMしようとすると、どうしてもコード量は多くなってしまう場面が多いですね…。

>これだと疎結合ではなく ViewModel の型を知ってることになりますが、このURLの方法よりも疎結合にしたほうが良いメリットはどういうことがありますでしょうか？

ご提示のURLの方法でも、ViewModelに渡すのが実装クラスの型でなくinterfaceならば、依存は限定的になるため、ある程度疎結合であるといえます（ラムダ式でも同じだと思います）
なのでこの方法でも良いと思いますが、個人的には結局ViewModel側で画面に関わる操作（MessageBox.Show）を呼び出すことになるという点であまり好みではないですね。
UIスレッドかどうかも意識しないといけないですし。

>疎結合が良いという話は聞きますが、私の中ではViewとModelは全く依存しない疎結合でいいと思うのですが～
画面をロジックと切り離したい一番の理由は、ロジックだけでテスタブルな設計にするためです。
またXAMLで画面を作るWPFのようなものならば、画面だけデザイナーがBlendで作ったりもできますし、表示確認のためにデバッグ用のDataContextを仕込んで動かしたりもできます。

ViewModelは完全にPOCOで、ViewとModelさえ疎結合ならば良いんだという考え方はそれはそれでありだと思いますが、
大抵はViewとViewModelを疎結合にできないならば、ViewModelとModelが結合するためにViewとModelも間接的に依存することになってしまうのではないかと思います。

[lazex]

なるほどです
参考になりました

Answer 2

VMからVを触る書き方は気持ち悪い。
今時の、xamarinのような複数のプラットフォームで動くもの作ることも念頭に置くとあり得ない実装。
VMとMの役割がだんだんわからなくなるなら同意しますが。

VMからVは、メッセージパターンを使うのが定番だったのですが、
メッセージパターンは古いやり方っぽくて、ドキュメントがある時点から一気に無くなる。
今時はDIを使い、こう作るみたいです。
http://sourcechord.hatenablog.com/entry/2016/01/23/170753

あんまり関係ないのですが
https://www.codeproject.com/tips/478643/mouse-event-commands-for-mvvm
は、結構便利です。
似たようなアプローチで、データバインドできないものができたりします。

Comments

[lazex]

xamarinについては全く詳しくないのですけど、VMからVを触ることができないような仕組みになってるのでしょうか

[kiichi54321]

Xamarinは、触ったことないのだけどw、Viewは、ネイティブ実装になるため、それぞれのプラットフォーム、iOS Androidで違います。命令そのものが違う。
この差を吸収するために、vmのvへの依存をなくして、インターフェースを使った呼び出しにすると、同じVM Mで、違うプラットフォームで動くものが作れます。ただし、viewは、それぞれ作らないとダメです。だから、xamarinは70%のコード共有を謳っている。
忘れていましたが、単体テストもできるようになるので、わざわざuiをいじってテストするということをしなくてすみます。これは、標準出力をviewにしている、みたいな理解もできると思います。
VMから、Viewを触ろうなんていう未練を断ち切るいい方法があります。ViewとVMのプロジェクトをわけるのです。そして、VMのプロジェクトをpclにするのです。pclは、いろいろとヘイトが溜まるのですが、いい拘束具になります。
ついでにちょっとだけでいいので、同じvmを使ってuwpで動くものを作ってみましょう。wpfとuwpは似たようなXaml で記述するのですが、細かいところがいろいろ違います。
こういうことをすると、vとvmを疎結合にすべきというのが、わかるんじゃないのでしょうか。移植がviewだけになるスタイルってことですね。まわりくどいけど。
そのため、ターゲットがwpfだけなら、厳密にやる必要はないのです。
だから、はじめの気持ち悪いという情緒的な表現になってしまうのですが。

[kiichi54321]

ちゃんと質問に答えていなかった。vmからviewを触るには、インターフェースを使って間接的にやります。直接はありえません。実体は、それぞれで、実装します。
あと、僕の言っているのは、viewはvmの型を知っていますが、vmはviewを知らない、という構成です。viewをなんでもいいとするためです。c#なんで、インテリセンスが効いて欲しいですし。
あと、本格的に作った時はどうなるかは、これがとても参考になります。
https://github.com/PrismLibrary/Prism-Samples-Windows/tree/master/AdventureWorks.Shopper

[lazex]

View はそれぞれ違うのですね。
WebのHTMLみたいに共通のもの（XAMLやViewのC#コード）を書けばあとは同じ動きをするようにフレームワークがどうにかしてくれるものだと思ってました。

Answer 3

回答修正:
Viewモデルはコンポーネントを作るものなので他の方がおっしゃってるように疎結合な実装の方がいいと思いました。ViewModelについて誤解があり無知な回答をしてしまってすみません。誤解を招く回答をしてしまったので回答記述は削除します。