C# – nibuiroフラグメント β

MVVM on WPF

MVVM on WPF

View

  • Modelの公開しているデータとコマンドを操作しやすいようにViewをつくる

 UIのことでありXAMLで記述される。Datacontextにクラスを指定してリソースとして利用するなどする。またCommandをバインディングする、ホットキーのバインドなどもxamlに記述される。viewが「UI/UXについて」、と考えればここでホットキーがバインドされることになんら問題はない。

Model

  • WPFで組んでいるものをFormsに変更することになると考えた場合に、変わらない部分をまとめるとモデルになる。

 a.k.a.エンジンで良いのではないかと。
 入力の検証はViewが変わったとしても変更されるわけではないのでModel側。Modelは変更通知機能を有することが許されていて、View側がModelからデータを直接受けとることはタブーではない。

ViewModel

  • ModelとViewで合わない部分を合うように変換する機能を作るとViewModelになる

 INotifyPropertyChanged、Command(ICommnad)などは基本的にここの枠組みに実装する。難読化が懸念されるほどのコマンド量が想定されれば適切な粒度で分類してファイルに分ける。Modelを継承したクラスに機能を追加してViewModelとしてもいい。役割はView専用の保持データの管理だと広く認知されている。ViewによってはModelに直接接続できない部分の変換を行う。言い換えると、View専用の表示に合うようにデータ整形する。逆に入力をModelに合うように整形する。
 表示することが目的のアプリの場合はページそのものがモデルで管理されるデータであるからViewModelでは管理しない。

識者によると、

「VMが注目されすぎて、Modelに実装すればいい機能までVMに実装してしまって、VMにMが混ざってしまうのが混乱する原因だと思う。」

「「Modelを継承してViewModelにしてやれば違いを意識せずに使えるよね」「後でVMにするならModelにINotifyPropertyChangedを実装してしまえ」という実装が楽ちんなのでよくやります。」

とのこと。

【C#】openCVによる二値化

環境

 NuGetパッケージ、OpenCvSharp3-AnyCPU ver3.4.1.20180319 を使用。

比較

 雑感です。

適応的閾値処理

Sauvolaの手法

大津の二値化