WPF/Silverlight/Windows Phone共通WeakEvent機構 - the sea of fertility
この記事はSilverlight Advent Calender 2011の12/11分の記事です。前日は@neueccさんの.NETの標準シリアライザ(XML/JSON)の使い分けまとめでした。 WeakEventとは？ WeakEventとはイベントハンドラの解除忘れによるメモリリークが発生しないイベント機構の事です。 .NETでメモリリークが発生する主要要因の一つとして、イベント受信側クラスがイベントハンドラの登録を解除しない事で発生するメモリリークが挙げられます。ステートレスなWebプラットフォーム上ではほとんど発生を考慮しなくて良い問題ですが、ステートフルなリッチクライアントではよく問題になります。WeakEvent機構はそのためのソリューションの一つとしてもともとはWPF用に用意されていた機構です。その証拠に.NET4ではWeakEventManagerなどのWeakEvent
クラスのインターフェースに使うコレクションのinterface使い分け - the sea of fertility
この記事は C# AdventCalender 2012 の12/17日分の記事です。 タイトルなんのこっちゃ？って思われるかもしれませんが、今年はMVVMとは関係ないC#erらしいタイトルを・・・という事自信がなくなるクラスのインターフェースに使う（プロパティの型として使う）コレクションinterfaceの使いわけを自身の整理のためにも書いてみます。 ようは public class Tweet{ } public class TwitterApplication { public [？(なんかコレクションのインターフェース)] Tweets{get; private set;} } みたいな時にこの「？」に何を使うかという問題ですね。 .NET4.5ではIReadOnlyCollection<T>/IReadOnlyList<T>/IReadOnlyDictionary<T>などの読み
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
MVVMパターンとは？ – わんくま同盟東京勉強会 #60 セッション資料 - the sea of fertility
僕のセッションの資料をアップします。 前回は時間オーバー。今回は10分も早く終わるとかorz。 わんくま同盟 東京勉強会 #60 http://www.wankuma.com/seminar/20110625tokyo60/ 普段ブログで書いているような話や、今までUPしたスライドのような話ではなくて、超初心者向けの内容です。 「一般的な設計原則とWPF/Silverlightの特徴から導出するMVVMパターン」という副題が付けてあります。 とりあえずSlideboomはパワポアニメもいけるようで大満足。 レビュー協力してくれた秘密組織 謎クエリの会のみんな、@xin9leさん本当にありがとう！。 課題 反省会という名の、いつものメンバー的な３次会で、「WeakEventの話はレベル１にふさわしくないんじゃないの？」という意見をもらっていたり。WeakEventパターンへの踏み込んだ解説は
MVVMパターンの適応 – 2011年のMVVMパターンの常識 - the sea of fertility
MVVMパターンに関する認識・知見があちこちに散らばっているように見えるので、そろそろまとめてみる事にしました。この記事は、他の各サイトの記事などでMVVMの基本的な考え方・実装方法などを把握されている方が対象です。 そういった方がMVVMパターンを実務に適応してみようと思った時や、MVVMパターンを要件に合わせてカスタマイズしていく際に、認識すべきパターンの実装方式のそもそもの理由と考え方、要件に合わせて考えていかなければならないポイントを把握する助けとなる情報を提供するのを目的としてこの記事を書きました。(文字ばかりですいません＞＜) MVVMの実装の各要素の実装をこねくりまわすばかりで、その過程でパターンを把握している気になって、パターンの本来の目的を破壊してしまうような実装を推奨してしまっている人も見ます。そんな滑稽な事をしない認識を持って欲しいのです。 MVVMパターンは、WPF
MVVMパターンとイベント駆動開発、そしてMVC/MVP/PMパターンとの関係 – 何故MVVMなのか - the sea of fertility
WPF/Silverlight開発において、イベント駆動開発じゃ何故いけないのか？ MVC/MVP/PMパターンとMVVMはどう違うのか、どういったメリットがあるのか？ そういう声を聴く機会は少なくありません。 MVVMパターンとイベント駆動開発、MVC/MVP/PMパターンとの関係について僕の理解をまとめました。 MVVMパターンをわざわざ適応する事に疑問がある方にはぜひ読んで欲しいと思っています。 また、このドキュメントを記述するにあたり@matarilloさん、@ufcppさん、@yfakariyaさん、諸先輩方３方に叩き台を見ていただき多くの指摘を頂くことができました。今回は頂いたフィードバックを受けて公開する形になっております。 押しつけがましくも一方的に依頼させていただいて、にも拘わらず非常に丁寧に様々な指摘・示唆を頂くことができました。 この場を借りてお礼申し上げます。ありが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
