もう年なのか・・と思えるほど体力的に徹夜が堪えてくるようになってきましたが話してきましたよん RIA アーキテクチャ研究会 第4回セミナー http://kokucheese.com/event/index/50383/
もう年なのか・・と思えるほど体力的に徹夜が堪えてくるようになってきましたが話してきましたよん RIA アーキテクチャ研究会 第4回セミナー http://kokucheese.com/event/index/50383/
最近俄かに出てきたのが、この MVPVM というパターン。MVVM をより発展させたパターンらしいです。図にするとざっとこんな感じらしい。 現状日本語で詳しく解説してるのは、MSDN マガジンの記事だけ。もっとも原文は英語なので、若干翻訳が怪しいとこあるけど。 WPF 向けのモデル - ビュー - プレゼンター - ビューモデル設計パターン 某所のやりとり*1を見ると、ある御仁が MVPVM のプレゼンターについて 「Presenter = コードビハインド」 なんて解釈してるけどそうじゃないよね。上記ドキュメント内のビューの項では MVPVM では、分離コードにコードを記述する必要はまったくありません とはっきり述べてます。 また面白いなと思ったのがビューモデルについて。ドキュメントではこんなこと言ってます。 MVPVM: ビューモデル 「MVP では、モデルは純粋なドメイン オブジェク
MVVMパターン的な実装は、他のプラットフォームでは選択肢の一つにすぎませんが、WPF/Silverlight(Windows Phone 7 含む)においては唯一の選択肢です。コードビハインドを書かないことはMVVMパターンそのものの定義とは関係ありません。まずはスキルにあったレベルでMVVMパターンを意識した実装を初めてみませんか? 以前の勉強会発表資料(わんくま勉強会での発表資料の半分以上をカットし、Androidテスト祭り分追加)を加工し、社内勉強会、そのほかの勉強会・ブログなどで自由に使える資料として公開します。私の個人名は抜いてあります。 無許可の改変・引用なども問題ありません。ただ、資料の直接の商用利用などはご遠慮ください。 ブログに張り付けたい場合、下のbマークから埋め込み用URLを取得できます。 「コードビハインドを書くのはMVVMパターンではない」などの誤解が、MVVM
In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...
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
WPF/Silverlight開発において、イベント駆動開発じゃ何故いけないのか? MVC/MVP/PMパターンとMVVMはどう違うのか、どういったメリットがあるのか? そういう声を聴く機会は少なくありません。 MVVMパターンとイベント駆動開発、MVC/MVP/PMパターンとの関係について僕の理解をまとめました。 MVVMパターンをわざわざ適応する事に疑問がある方にはぜひ読んで欲しいと思っています。 また、このドキュメントを記述するにあたり@matarilloさん、@ufcppさん、@yfakariyaさん、諸先輩方3方に叩き台を見ていただき多くの指摘を頂くことができました。今回は頂いたフィードバックを受けて公開する形になっております。 押しつけがましくも一方的に依頼させていただいて、にも拘わらず非常に丁寧に様々な指摘・示唆を頂くことができました。 この場を借りてお礼申し上げます。ありが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く