Messengerを理解するために自作してみた(1)-(3) Messenger+Behaviorを理解するために自作してみた(1)-(3) でとりあえず、コードビハインドにコードを記述せずに、ViewModelからViewを操作する 方法については理解したつもりだけれど、 それでも、今の僕の経験と知識では、コードビハインドに次のようなコードを書いても、 良いんじゃないかなーと思ってます。 private void button1_Click(object sender, RoutedEventArgs e) { if (MessageBox.Show("実行しますか", "確認", MessageBoxButton.YesNo) == MessageBoxResult.Yes) { vieewModel.Execute(); } } こう主張すると、 「コードビハインドにView以外のロ

よくTwitter上などでMVVMパターンの学習は難しいという話を聞きます。最近その理由と認識のずれが少しづつ解ってきたので、書いてみる事にしました。 ネット上には様々なサンプルコードがありますが、「MVVMパターンを使う」という視点で学習する場合、用意した開発環境によって学習する事は異なってきます。 何故なら、設計パターンの思想の再現度は「その設計パターンのためのライブラリと環境」によって大きく異なるものだからです。 ASP.NET MVCが導入できない状況でASP.NET MVCをやろうとしますか？。そんな事をしようとすると業務ドメインのロジックに注力するどころか、MVCの概念を正しく理解しているのはもちろんの事、ASP.NETパイプラインの仕様に詳しく精通している必要もあります。他の環境(例えばRubyにおけるRails)でMVC補助がどうやって成立しているかも踏まえた上でインフラス

前回の続きです。前回までで、Messenger + Behavior の準備はできました。 つまり、フレームワーク側が出来たということです。 では、この簡易フレームワークをつかって、実際に、ViewModelからメッセージを 送り、Viewを操作してみます。 以下のようなプログラム（以前示したものと同じ）を作成します。 今回は、Viewのコードビハインドには、初期状態のまま、何もコードを追加しません。 ■ XAMLの実装 サンプルプログラムのXAMLを示します。 <Window x:Class="MyMessengerSample.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml

.NET開発者中心 厳選ブログ記事 MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？ ―― 「the sea of fertility」より ―― 尾上 雅則 2011/05/18 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 MVVM（Model-View-ViewModel）パターンに関する知見があちこちに散らばっているように見えるので、そろそろまとめてみることにしました。この記事は、MVVMの基本的な考え方・実装方法などを把握されて

Livet WPF4 MVVM インフラストラクチャ ProjectHome : http://ugaya40.net/livet SourceCode : https://bitbucket.org/ugaya40/livet/ Livetの概要と導入方法 LivetはWPF4のためのMVVM(Model/View/ViewModel)パターン用インフラストラクチャです。.NET Framework 4 Client Profile以上で動作し、zlib/libpngライセンスで提供しています。zlib/libpngライセンスでは、ライブラリとしての利用に留めるのであれば再配布時にも著作権表示などの義務はありません。しかし、ソースコードを改変しての再配布にはその旨の明示が義務付けられます。 Livetの目指すところ 現在、WPFでMVVMパターンによる実装を行うにはインフラストラクチャの

■はじめに これまで、3回に亘って、Messengerクラスを自作することで、MVVMにおける Messengerについて理解を深めようとしてきたわけですが、今回は、 「Messenger + Behavior」を使い、ViewModelからViewを操作する方法について考 えてみます。 XAMLにビヘイビアを記述することで、Viewのコードビハインドに、何も記述せずに、 ViewModelからViewを操作できるようになるらしいので、オレオレBehavior を実装して、 これを確かめてみようと思います。 この記事の趣旨は、 MVVMフレームワークがどうやって、Messenger + Behavior を 実現しているかを、理解することなので、当然、Expression Blendに付属している System.Windows.Interactivity も利用しません。 最低限のものを自

それでは、前回作成した Messengerクラスを使い、ViewModelからViewにメッセージを送ってみます。 以下のような簡単なプログラムを作成してみます。 TextBoxに文字列を入れ、ボタンを押すとダイアログが表示されるという単純なものです。 まずは、Windowクラスです。 public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); Messenger.Default.Register<DialogBoxMessage>(this, ShowMessage); } public void ShowMessage(DialogBoxMessage msg) { var result = MessageBox.Show(msg.Message, "確認", msg.B

前回の続きです。 Messageクラスが定義できたので、次は、Messengerクラスの定義です。 このMessengerクラスには、２つのメソッドを定義します。ひとつは、Register。 もうひとつは、Send メソッドです。 Registerメソッドは、View側で利用するもので、メッセージの型情報と「デリゲート」を 関連付けるものです。 この「デリゲート」は、ViewModelから、Messengerを経由して間接的に呼び出されます。 Sendメソッドは、ViewModelで利用されます。 このSendメソッドは、引数で渡されたMessageオブジェクトに対応したデリゲートを 呼び出す機能を持ちます。 この対応付けは、先ほどのRegisterメソッドで対応付けしたものです。 では、Messengerクラスの実装をしてみます。 public class Messenger { pri

MVVMを勉強していたら、Messengerというものが出てきました。 これって何だろうか。 .NET Frameworkのクラスじゃなくて、MVVM Light Toolなどのフレームワークで 用意されているもので、ViewModelからViewを操作する時に利用するもののようです。 要は、ViewModelとViewの仲を取り持つ仲介者クラスです。 と、ここまでは分かりましたが、それ以上のこと(特にどういう仕組みなのか)が良くわかりません。 そこで、理解を深めるために、MVVM Light Toolの外部インターフェイスを参考に Messengerクラスをちょっと自作してみました。 とはいっても、ものすごい手抜きなので、これを実際に使うわけにはいかないと思うし、 MVVM Light Toolのソースコードは一切みていないので、僕の理解が間違っている可能性は ありますが、まあ、Mess

僕はGoogleやTwitter検索で定期的にMVVMというキーワードで検索を行っています。 そこでこんな素敵な記事を見つけました。 MVVMのメリット・デメリットを見つめなおす wave1008の日記 http://d.hatena.ne.jp/wave1008/20110227 基本的にMVVMパターンの大目標(ドメインロジックとプレゼンテーションロジックの分離)には賛同されているものの、ビヘイビアやコマンドの仕様には否定的な記事です。書かれている内容は非常に説得力があり、素晴らしい記事です。驚くほどこういった記事は少ないので、大変勉強になりました。是非皆さんも一読してみてください。 素晴らしい突込みとは思うのですが、一年以上MVVMを追い続けた人間として素直にこの内容の視点に賛同できるというわけではないので、少し僕の考え方を書いてみたいと思います。 反論の前提として、僕はMVVMイン

先日MVVMをDISったが、説明不足気味でDISりっぱなしでは無責任かと、ちと反省している。 SilverlightでMVVMを使うのは問題があるので昔ながらのWindows Formsスタイルの開発に戻るべきだと受け取られたとしたら、それは誤解である。Silverlight（あるいはWPF）ではもはやWindows Formsスタイルの開発はできないし、そうすべきではないからだ。なので、今日はフォロー記事を書いてみる。 Silverlightの各コントロール群はMVVMの特徴であるデータバインドを前提に設計されている。なので、従来のWindows Formsスタイルの開発はできなくなっている部分が多々ある。 たとえばDataGrid。Windows FormsのDataGridViewならばセルの何行何列をインデックス指定すればセルのオブジェクトを取得でき、さらに背景色やフォント色などの

MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基本的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません＞＜) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの本来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF

日本時間本日早朝(2010/12/03)、米国 でのイベントSilverlight Fire Starterのキーノートにおいて、Silverlight 5が発表されました。 WPFの存在意義を脅かすほどのSilverlightの機能強化が発表される中、The Future of Microsoft SilverlightとしてMVVMパターン用サポートがSilverlight 5 標準に公式に採用される事が発表されました。 Model View ViewModel (MVVM) and Databinding enhancements allow more work to be done more easily via XAML: Debugging support now allows breakpoints to be set on a binding, so you can ste

Collaborate for free with online versions of Microsoft Word, PowerPoint, Excel, and OneNote. Save documents, workbooks, and presentations online, in OneDrive. Share them with others and work together at the same time.

MVVM パターンの ViewModel の作成の仕方について聞かれることがたまにある。 MVVM パターンの ViewModel は View に対して１つ作る。 Window や UserControl に対して作成するのは分かりやすいが Panel やその継承など 関連性が高い情報をまとめて  ViewModel にすることもできる。 ItemsControl やその継承は ViewModel のコレクションとして持つことになる。 View は、VisualTreeHelper や Snoop を見ればわかるように Tree 構造になっている。 したがって、 ViewModel も Tree 構造になるべきだ。 具体的には、親は VisualTree に合った 子供の VM を ContentControl やその派生クラスなら インスタンスを持って管理し、 ItemsControl