C#を使用したMVVMの基本について

Question

###前提・実現したいこと
MVVMで、Web検索しますと、複数の解釈とコード例が検索されますが、基本的な例が見つかりません。
そこで、MS社の資料を参考にC# Prism Unityで、MVVM構造の単純なプログラムを作成しました。

＜作成内容＞
「各テキストボックスに、ある数Aとある数Bを入力し、ボタンを押すとラベルに結果を表示する。」

＜課題＞
素直に、そのまま作りますと、只の足し算が信じられない複雑なプログラムになりました。
簡単なプログラムにする良い方法を検討しています。

###ここに質問したいことを詳細に書いてください

C# Prism Unityで、MVVM構造プログラムを作成する場合、定石的な方法で、簡単なコードをご教授下さい。

###該当のソースコード

マイクロソフト社の解説書
CompositeWPF-June2008-JA-JP.chm
MVVM関連
https://www.microsoft.com/ja-JP/download/details.aspx?id=39042

（複雑になった基本プログラム）

1．準備
VisualStudioCommunity2015
wpfアプリケーションのプロジェクト
NuGetパッケージ管理より
Prism、Prism.Unitをインストール

2.Composite Application Libraryを学ぶ
2-1 App.XAML

<Application x:Class="WpfMVVMPrism.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="clr-namespace:WpfMVVMPrism"
    Startup ="Application_Startup">
    <Application.Resources>
    </Application.Resources>
</Application>

2-2 App.XAML.cs

using System.Windows;
namespace WpfMVVMPrism
{
    /// <summary>
    /// App.xaml の相互作用ロジック
    /// </summary>
    public partial class App : Application
    {
        private void Application_Startup(object sender, StartupEventArgs e)
        {
            var boot = new Bootstrap();
            boot.Run();
        }
    }
}

2-3 Bootstrap.cs Shellをコンテナに登録（最小コード）

using System.Windows;
using Microsoft.Practices.Unity;
using Prism.Mvvm;
namespace WpfMVVMPrism
{
    /// <summary>
    /// Unity コンテナーを使用する。
    /// </summary>
    public class Bootstrap : Prism.Unity.UnityBootstrapper
    {
        protected override DependencyObject CreateShell()
        {
            return this.Container.Resolve<Shell>();
        }

        protected override void InitializeShell()
        {
            ViewModelLocator.SetAutoWireViewModel(this.Shell, true);
            ((Shell)this.Shell).Show();
        }
    }
}

2-4 Shell.XAML

<Window
    x:Class="WpfMVVMPrism.Shell"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:local="clr-namespace:WpfMVVMPrism"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    Title="MVVMの基本その１(計算 A+B=C)"
    Width="350"
    Height="200"
    mc:Ignorable="d">
    
    <!-- <Window.DataContext>
        <local:ViewModel />
    </Window.DataContext> -->
    
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition />
        </Grid.ColumnDefinitions>

        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition />
            <RowDefinition />
            <RowDefinition />
        </Grid.RowDefinitions>
        <TextBox
            x:Name="textBoxA"
            Grid.Row="0"
            Text="{Binding DataA}" />
        <TextBox
            x:Name="textBoxB"
            Grid.Row="1"
            Text="{Binding DataB}" />
        <Button
            x:Name="button"
            Grid.Row="2"
            Content="「A+B=C」の計算をする" 
            Command="{Binding CalculationCommand}"/>
        <Label
            x:Name="labelC"
            Grid.Row="3"
            Content="{Binding ResultC}" />
    </Grid>
</Window>

2-5 Shell.XAML.CS

using System.Windows;
namespace WpfMVVMPrism
{
    /// <summary>
    /// Shell.xaml の相互作用ロジック
    /// </summary>
    public partial class Shell : Window
    {
        public Shell()
        {
            InitializeComponent();
            this.DataContext = new ViewModel();
        }
    }
}

2-6 VeiwModel.cs

using System;
using System.ComponentModel;
using System.Windows.Input;
namespace WpfMVVMPrism
{
    public class ViewModel : INotifyPropertyChanged
    {
        public int DataA { get; set; }
        public int DataB { get; set; }

        public event PropertyChangedEventHandler PropertyChanged;
        private int _resultC;
        public int ResultC
        {
            get
            {
                return _resultC;
            }
            set
            {
                _resultC = value;
                OnPropertyChanged("ResultC");
            }
        }

        protected void OnPropertyChanged(string name)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (handler != null)
            {
                handler(this, new PropertyChangedEventArgs(name));
            }
        }

        private ICommand _calculationCommand;
        public ICommand CalculationCommand
        {
            get
            {
                if (_calculationCommand == null)
                {
                    _calculationCommand = new RelayCommand(ExecuteCalculationCommand);
                }
                return _calculationCommand;
            }
        }

        private void ExecuteCalculationCommand(object x)
        {
            Model m = new Model();
            m.a_val = DataA;
            m.b_val = DataB;
            ResultC = m.SumAB();
        }
    }

    internal class RelayCommand : ICommand
    {
        private Action<object> executeCalculationCommand;

        public RelayCommand(Action<object> executeCalculationCommand)
        {
            this.executeCalculationCommand = executeCalculationCommand;
        }

        public event EventHandler CanExecuteChanged;  

        public bool CanExecute(object parameter)
        {
            return true;
        }

        public void Execute(object parameter)
        {
            this.executeCalculationCommand(parameter);
        }
    }
}

2-7 Model.cs

namespace WpfMVVMPrism
{
    public class Model
    {
        public int a_val;
        public int b_val;
        public int c_val;

        public int SumAB()
        {
            return c_val = a_val + b_val; 
        }
    }
}

以上です。

Answer 1

まあ、足し算のみで使うのはオーバースペックでしょうね。

http://qiita.com/hiki_neet_p/items/e381c687b0644c0e4978
の例では、肥大化しているのは非同期処理を書いている部分です。
巨大な非同期処理のコードの中に足し算の処理がまみれてしまうのを避け、Modelに分けることでビジネスロジックをスッキリさせています。

それこそ大企業向け（別に中小でも構わない）の複雑なビジネスモデルと記述するのに、レイヤー化された開発モデルは大規模開発の際に分業をしやすくします。

あと、工数が増える一切の作業はするべきではありません。システムは効率化のために使いましょう。
足し算にMVVMモデルを使うのはそういう意味で間違いで、電卓を渡すのが正解でしょう。適切な例が大規模になりすぎる場合があります。それはそれと考えるのが適切だと思います。

また、いろいろなアーキテクチャがありますが、基本的にはModelにビジネスロジックを集中させ、入出力を分けるのが一般的です。オブジェクト指向を機能させたり、自動化されたユニットテストをするためのほとんど必須の要件だからです。

MSDNの説明はわかりにくいものも多くありますが、サンプルコードもあり、他のモデルを理解している人には理解出来るものと思われます。私の場合、理解しづらい場合は入門書のようなものに当たってから見るようにしています。

Comments

[maroaig]

ご回答有難うございます。MVVMを実現する為に、工数を使うメリットがあるのか？議論の余地がありますよね。従来MSが推奨していた方式で短納期で作成する。もう過去でしょうか？ユニットテストも、分業もMVVMが必要とは限りません。工夫次第ですよね。私の場合はMVVMをパターン化し、最小工数で作れれば、合理的な作成方法と信じているのですが、技術的に直観的でなく使いにくいとも思ってます。
「入門書」？、MVVMを現場で使いたいと思う程、納得してません。従来よりも大変な作業になると思うのみです。私は、勉強不足なのでしょう。少しコードを書いてMVVM+Prismに慣れるようにしたいと思います。ご意見有難うございました。お仕事頑張って下さい。

[iwamoto_takaaki]

質問と思われる場所に回答します。いちいち答えすぎかもしれませんが悪気はありません。

＞MVVMを実現する為に、工数を使うメリットがあるのか？議論の余地がありますよね。

それは個々の条件によるものですし、メリット・デメリットの重づけは主観によるところもあります。（メリット・デメリットは議論可能ですが・・・）
プロジェクトの現在・将来の状況に合わせての判断なので、プロジェクトメンバーならともかく私は議論に参加できません。

＞従来MSが推奨していた方式で短納期で作成する。もう過去でしょうか？

これは引用でしょうか？だとしたら、なんの引用でしょうか？文脈がわからず回答できません。

＞ユニットテストも、分業もMVVMが必要とは限りません。工夫次第ですよね。

そうです。ほかの方法でも良いです。工夫の仕方としてModelを分離するというのは一般的で優れた方法の一つだと思います。

＞「入門書」？、MVVMを現場で使いたいと思う程、納得してません。

公式などでわかりずらい場合、導入の評価を行うには入門書（薄めのモノ）を読むのをお勧めします。短い時間で使い方のイメージをつかむことができます。現場で使うときは、もっと詳しい資料（厚めのモノ）にあたるといいと思います。

[maroaig]

ご回答有難うございます。書籍も日本語に翻訳されるペースが、追いつかない状態ではと感じます。英文を読まなければ仕事にならない時代になりました。パソコンの翻訳機能が頼りです。
MVVM入門では
http://www.atmarkit.co.jp/ait/articles/1011/09/news102.html
このURLは、分かり易いと思いました。

Answer 2

例えばテキストエディタを開発するとします。
最初の要件では TextBox を使い、ファイルのロードやセーブ・検索・置換などの機能を Form のメソッドとして持たせることになりました。

しかし、このエディタに思わぬ人気が出て、ユーザーから様々な要望が寄せられるようになりました。そこで開発陣はそれに応えるために TextBox をやめて AvalonEdit を使うことになり、Form は Window に変え、一から全部書き直しました。

こういう開発の仕方もあります。しかし、アプリケーションの規模が大きくなればなるほどフルスクラッチで書き直すことの負担は大きくなるでしょう。

MVVM で開発する時は、最初に View として TextBox と Form を選びます。そしてテキストエディタとして必要な振舞い(ロード・セーブ・検索・置換など)を Model として実装し、その両者をつなぐために ViewModel を書きます。Model はとにかくテキストエディタとしてこう振舞うべきという理想を追求します。ここで、TextBox および Form を開発するマイクロソフトと、Model を開発する班とで完全な分業が行われます。どちらも互いに依存していません。

さて View を AvalonEdit と Window に変えました。この時、書き直すべきは ViewModel だけです。しかし、View も Model もできているので、それらを部品として組み立てていくだけの作業であり、最初からフルスクラッチで書くのとは仕事量が大きく違います。

アプリケーションのすべてを自分で開発するのであれば、MVVM はもしかしたら無用なのかもしれません。しかし、他社の開発した部品を使うのであれば、そのバージョンアップや採用状況に合わせて柔軟に対応しなければなりません。この時、アプリケーションのソースすべてがその部品に依存していたとしたら、全部書き直さなければなりませんが、可能な限り分離することで書き直さなければならない範囲を大きく削減することができます。

Comments

[maroaig]

Zuishinさん、こんにちは、MVVMを使うと、仕様変更に対応し易い。これは心から本当にそう思えますか、私は、Prismを使って、MVVMを作るのも大変、細かく分解されたソースから処理を追うのも一苦労しています。手続き型というより、関数型の処理になってます。昔流で言いますと、関数イベントの乱打、goto文のマカロニスパゲッティ状態です。この疎結合状態であるので、ある機能を交換しても、大丈夫、イベントを繋ぎ直す手間で交換できます。この理論は分かりますが、私は、その作業、ストラクチャ方式より、難解と思えます。Prismメッソッドの組み合わせ動作に慣れるのが、一苦労ではなかったでしょうか？従来方式より、改善されましたか？

[Zuishin]

誰が作ったかにもよります。スパゲッティをゆでる人は何でもスパゲッティにします。

[Zuishin]

たとえばデータベースアプリケーションであれば、DataGridView が View です。Entity が Model です。それをつなぐあなたのコードが ViewModel です。どこかわかりにくいですか？

Model を作らず、ソースのあちこちで SQL を使う方法も確かにあります。こちらの方がわかりやすいですか？

[maroaig]

ご回答有難うございます。最近は、DataGridViewなどは、Unitテストができないからダメだそうです。これも、カスタムクラスを作ります。私は、DataGridViewはそのまま使う主義でしたので、内部クラスの関係がどうなっているのか辛いです。兎に角、芸が細かいのです。Entityフレームワークも、Oracle用に、カスタムクラスを作ります。データのキャッシュクラスも作ってます。

[Zuishin]

一例です。まだ複雑過ぎますか？噛み砕くのも限界がありますが。

[Zuishin]

足し算をモデルにしているのも一例ですよ。普通こんなものをモデルに分ける人なんかいません。これをもって複雑だ複雑だと騒ぐのはナンセンスです。

足し算だけするオブジェクトを作って、「オブジェクト指向は複雑だ。素直に足した方がわかりやすい」と騒いでいるようなものです。

[ozwk]

足し算でさえこんなに複雑なコードなるんだから
もっと複雑なモデルならもっと複雑なコードになるという考えなのでは?

[Zuishin]

複雑にしようと思えばいくらでも複雑になりますけど、足し算モデルが複素数の四則演算と集合演算モデルになってもそんな変わらないんじゃないですか？

[maroaig]

ViewModelとModelの関係ですか？、疎結合にしないと、インターフェース変更しないで、足し算モデル、複素数演算モデル、集合演算モデルなどに交換できるように、う～？

[Zuishin]

誰もそんなこと言ってません。話がそれています。疑問が無いのなら自己解決でもしたらどうでしょう？ 何か主張したいだけなら次回からは Qiita にでもどうぞ。

[maroaig]

私には、良く理解できないのですが、コードを実用化したいと思っているだけです。問題が有るのでしょうか？ご教授よろしくお願いいたします。

Answer 3

4 Model側をイベント処理化します。（モデルの疎結合化）
4-1 Shell.XAMLの追加修正

<Window
    x:Class="WpfMVVMPrism.Shell"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:local="clr-namespace:WpfMVVMPrism"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    Title="MVVMの基本その２(計算 A+B=C,A*B=D)"
    Width="350"
    Height="200"
    mc:Ignorable="d">
    
    <!-- <Window.DataContext>
        <local:ViewModel />
    </Window.DataContext> -->
    
    <Grid>
        <Grid.ColumnDefinitions>
            <ColumnDefinition />
        </Grid.ColumnDefinitions>

        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition />
            <RowDefinition />
            <RowDefinition />
            <RowDefinition />
        </Grid.RowDefinitions>
        <TextBox
            x:Name="textBoxA"
            Grid.Row="0"
            Text="{Binding DataA}" />
        <TextBox
            x:Name="textBoxB"
            Grid.Row="1"
            Text="{Binding DataB}" />
        <Button
            x:Name="button"
            Grid.Row="2"
            Content="「A+B=C, A*B=D」の計算をする" 
            Command="{Binding CalculationCommand}"/>
        <Label
            x:Name="labelC"
            Grid.Row="3"
            Content="{Binding ResultC}" />
        <Label
            x:Name="labelD"
            Grid.Row="4"
            Content="{Binding ResultD}" />
    </Grid>
</Window>

4-2 ViewModel.cs の追加

using Microsoft.Practices.Prism.Commands;
using Microsoft.Practices.Prism.Mvvm;
using Prism.Events;
using System;
namespace WpfMVVMPrism
{
    public class Addition : PubSubEvent<Tuple<int, int, Action<int>>> { }
    public class Multiplication : PubSubEvent<Tuple<int, int, Action<int>>> { }
    public class ViewModel : BindableBase
    {
        private EventAggregator events;
        public int DataA { get; set; }
        public int DataB { get; set; }

        private int _resultC;
        public int ResultC
        {
            get { return _resultC; }
            set { this.SetProperty(ref this._resultC, value); }
        }

        private int _resultD;
        public int ResultD
        {
            get { return _resultD; }
            set { this.SetProperty(ref this._resultD, value); }
        }

        private DelegateCommand _calculationCommand;
        public DelegateCommand CalculationCommand
        {
            get
            {
                if (_calculationCommand == null)
                    _calculationCommand = new DelegateCommand(ExecuteCalculationCommand);
                return _calculationCommand;
            }
        }

        public ViewModel()
        {
            this.events = new EventAggregator();
            var model = new Model(this.events);
        }

        private void ExecuteCalculationCommand()
        {
            ResultC = this.events.GetEvent<Addition>().CalData(DataA, DataB);
            ResultD = this.events.GetEvent<Multiplication>().CalData(DataA, DataB);
        }
    }

    static class lib
    {
        public static Result CalData<D1, D2, Result>
            (this PubSubEvent<Tuple<D1, D2, Action<Result>>> @this
              , D1 data1
              , D2 data2)
        {
            Result ret = default(Result);// Null
            Action<Result> CallBack = x => { ret = x; };
            @this.Publish(Tuple.Create(data1, data2, CallBack));
            return ret;
        }
    }
}

4-3 Model.cs の追加

using System;
using Prism.Events;
namespace WpfMVVMPrism
{
    public class Model
    {
        private EventAggregator events;

        public Model(EventAggregator events)
        {
            this.events = events;
            this.events.GetEvent<Addition>().Subscribe(SumAB, true);
            this.events.GetEvent<Multiplication>().Subscribe(MultiplicationAB, true);
        }

        private void SumAB(Tuple<int, int, Action<int>> cal)
        {
            var ans = cal.Item1 + cal.Item2;
            var CallBack = cal.Item3;
            CallBack(ans);
        }

        private void MultiplicationAB(Tuple<int, int, Action<int>> cal)
        {
            var ans = cal.Item1 * cal.Item2;
            var CallBack = cal.Item3;
            CallBack(ans);
        }
    }
}

この方式ですと、複雑で良い方法とは思えないのです。明快な解決策は無いでしょうか？

Comments

[hihijiji]

MVVMインフラの中では、Prism はプレーンに近いです。
最終的に Prism をベースにインフラを構築するのは良いのですが、その前に MVVM Light と Livet の両方を使って見ることをお勧めします。
目から鱗が幾つか落ちると思います。

[maroaig]

ご教授有難うございます。「MVVM入門その４ライブラリを使おう」MSにお勤めのかずきさんのご紹介例を見てますが、https://code.msdn.microsoft.com/windowsdesktop/MVVM-0675495f
私としては、「簡単になってるのかなぁ」と思うばかりで、hihijijiさんは、どの辺で、「目から鱗が」となったのでしょうか？

[hihijiji]

その簡単にするやり方です。

[maroaig]

簡単ですか?どの視点から考察するかが大事だと思います。たとえば、AIは簡単便利と言いましても、製作側から見れば、複雑だなぁとなります。また、自分で作る物は簡単に思え、他人が作ると複雑に見えますね。このライブラリも、プラモデルのように、設計図どうりに組み立てるユーザーであれば、簡単便利なツールの類ではと思います。

Answer 4

3 検討結果
3-1 VeiwModel.csを実用的に改良する

using Microsoft.Practices.Prism.Commands;
using Microsoft.Practices.Prism.Mvvm;
namespace WpfMVVMPrism
{
    public class ViewModel : BindableBase
    {
        public int DataA { get; set; }
        public int DataB { get; set; }

        private int _resultC;
        public int ResultC
        {
            get
            {
                return _resultC;
            }
            set
            {
                this.SetProperty(ref this._resultC, value);
            }
        }

        private DelegateCommand _calculationCommand;
        public DelegateCommand CalculationCommand
        {
            get
            {
                if (_calculationCommand == null)
                    _calculationCommand = new DelegateCommand(ExecuteCalculationCommand);
                return _calculationCommand;
            }
        }

        private void ExecuteCalculationCommand()
        {
            Model m = new Model();
            m.a_val = DataA;
            m.b_val = DataB;
            ResultC = m.SumAB();
        }
    }
}

BindableBaseクラスを継承、ICommandをDelegateCommandに変更すると、作成の手間が減少しました。

Answer 5

MVVMパターンでの情報のやり取りは実行時に行うもので、設計時の打ち合わせとは別ものであると考えております。

テキストボックスに入力できる数値の桁数は、View を設計するときに必要ですよね？
一桁なのか一万桁なのか分からなければ View を設計しようがないですから。
同様に、足し算などの固定的で単純な処理は View の設計に盛り込んでも問題ないと思います。
残念ながら XAML には四則演算がないので、VM で行わざるを得ませんが…

Comments

[maroaig]

hihijijiさん、おはようございます。どこかでお会いしたことが有るかもしれません。VBAがお得意では？
さて、本題ですが、画面の設計での打ち合わせで、MVVMパターンが話題になるとすれば、画面のデザイナーと、プログラマーの作業を分離する手法ですね。Microsoft Expression Blendツールでインターフェースを作成する場合、テキストボックスの幅など見た目は大事ですが、桁数は、プログラマーにお任せでは無責任でしょうか？（テキストボックスは、横スクロールしますし）
XAML言語ですが、Convertや、クラスのカスタマイズも、MVCパターンで、数値変換を良く見ます。
C＃で数値演算するのですが、まるでXAML言語の拡張のようにも見えます。
XAMLのソースもオープンになってますから、MS社のみではなく、一般の人もクラスのカスタマイズできます。でも、私から見ますと、相当に難しいとおもいます。

[hihijiji]

言い方を変えてもう一回書きます。
・MVVMパターンを採用してもModel側の管轄下にある情報の全てを実行時にModelに問い合わせする必要はありません。
・Model側の管轄下にある情報でも、実行前から分かっているものならView側の仕様に落とし込んでもいいのです。
もちろんそれによって仕様や実装が複雑になるのは本末転倒です。

PS. VBA は苦手です ^^;
VBAは本家のフォーラムを中心に頻りに書き込みを行っていたことがありましたね。
本家のフォーラムは当時カテゴリの統廃合が活発だったので、VBAカテゴリの存続に危機感を覚えたが故の行動でした。
---私が大昔に乱発した不出来なVBAアプリ群--- それらを含め今となっては黒歴史です。
忘れて頂けたら幸いです。

[maroaig]

ご回答ありがとうございます。う～、設計パターンに縛られるのも嫌です。柔軟性も欲しいです。しかし、調和、バランスも、そのうち、AIが勝手に判断すると思います。VBA言語も、ファッション業界のように、昔のデザインを少しアレンジして、最新ファッションになる事もありますから。学生さんの教育用になど、注目されると思います。

[hihijiji]

>設計パターンに縛られるのも嫌です。柔軟性も欲しいです。
設計パターン(MVVMパターン)を採用したいけど実装が複雑になるのは避けたいってことでは無かったのですか？
MVVMパターンの解釈の仕方が、面倒くさい方に偏ってるみたいなので、もう少し柔軟に考えては？とアドバイスしているのですが？

[maroaig]

おはようございます。ここ１０年の、ソフトウェア製作の方向性は、クラスの疎結合、仕様変更に対応し易い構造を重視している様子です。MSでは、「patterns&practices」このチームが中心と思うのです。

Prism Library 5.0 for WPFの開発者向けガイドの参考文献
https://msdn.microsoft.com/en-us/library/gg405487(v=pandp.40).aspx

２００８年頃に考案されたようで、日本の現場に反映されるのに、１０年余り経過しています。私も「MVVMパターンの解釈の仕方が、面倒くさい方に偏ってるみたい」同じ気持ちです。
Prismを軽量にアレンジしたXXXライトというのも存在するらしいです。詳しくは知りません。

Unity Containerに、View、ViewModel,　Modelを登録し管理する用にすれば、簡単になるのではと思っています。