「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita
※2022/04/23 追記 本記事の続編として、以下の記事を書きましたので、合わせて御覧ください。 仕事でSwiftUIでTCAを使ってみて、かなり知見がたまったので、その解説です。 MVVMからTCAへの移行を考えているのであれば、参考になると思います。 宣言的UIに、MVVMって不要なのでは？ iOS開発の現場で、宣言的UIが当たり前に使われるような時代になりました。 SwiftUIの開発体験、素晴らしい です。最高です。 しかし最近、SwiftUIで当たり前のように 「MVVMで開発しよう」 となったときに、 「ほんとにそれでいいんだっけ？」 と疑問に思いました。 自分の考えを深掘ってみると 問い: iOS開発で、宣言的UIにMVVMを採用することは本当にいいんでしたっけ？ 結論: 「SwiftUIを使うのであれば、MVVMを採用するのは止めよう」 理由： ViewModelの存在
MVVMとはなんぞやを公理から求めてみる - 滅入るんるん
MVVM(Model-View-ViewModel)はC#/.NET1の世界で生まれたアーキテクチャーですが、今では他の世界(Androidとか)でも利用されています。 しかしながら、C#/.NETの世界から他の世界へ輸出される際に間違った解釈で移されていたり、言語・フレームワーク上の性質から妥協をしすぎて本来のMVVMとは言えないものまでMVVMと呼ばれていることもあります。 今回はそのMVVMの公理を定めて、「公理」から「定理」を導いてみようというものです。 アーキテクチャーを語るうえで重要なこと アーキテクチャー(および設計)は多種多様な価値観があり、それぞれの側面から見たら正解であり違う側面から見たら間違いであることがあります。 最初の考案者が提案したアーキテクチャーが進化と伝染を遂げるごとに最初に提示されたものとは違うものがそのアーキテクチャーとして認識されることもあるでしょう。
MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？（1/5） - ＠IT
.NET開発者中心 厳選ブログ記事 MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？ ―― 「the sea of fertility」より ―― 尾上 雅則 2011/05/18 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 MVVM（Model-View-ViewModel）パターンに関する知見があちこちに散らばっているように見えるので、そろそろまとめてみることにしました。この記事は、MVVMの基本的な考え方・実装方法などを把握されて
AvalonからMVVM、そしてRxへ: GUIプログラミングの哲学の歴史
MSテクノロジ知らんがな、とよしぞうに言われて、そういえばこの辺の話は外ではあまり聞かないな、と思ったので、ちょっと軽く振り返ってみる。 なお、Javaプログラマ向けに一部翻訳してるので、C# の実際とはちょっと違う。 かつて人々は、onclickでリクエストを発行しデータを取ってきて、その間はローディング中としてアイコンを回したりして、帰ってきたらアイコンを戻して取得したデータからtableを組み立てたりしていた。 このシーケンシャルな手続きプログラムは、非同期なGUIという物と大層相性が悪く、すぐにアイコンが回り続けたり途中で何か違う事をすると落ちたりといったバグを埋め込んでしまい、人々は悩んでいた。 GUIプログラムのバグはどこから来るのだろうか？ それはページの動的な所から来る、という観察があった。 静的なhtmlはあまりバグらない。 一旦動く、という事が静的に確認されれば、それ以
AvalonからMVVM、そしてRxへ(その2): GUIプログラミングの哲学の歴史
何故か書きかけで放り投げた前編が妙に反響あったので、一応続きも書いておく。 UIのプログラムというのを、準静的に書く為だけに存在するViewModelという物を導入する事にして、現実の要求と準静的なUIのギャップをだいたい埋める事に成功した人類だが、2つほど問題が残った。 1. UIからViewModelへの通知の粒度のミスマッチ 2. GUIアプリでは非UIの機能を非同期で実装しなくてはいけないが、そことViewModelのマッピングでかつての動的なGUIと似た問題が発生してしまう まず1について。 MVVMにおいては、直接イベントはハンドリングせず、基本的なUIの変化はViewModelのフィールドの変化にマッピングする(かICommandにマップする)。 例えばテキストボックスに値を入れると、対応するViewModelのstring型のメンバ変数(のsetter)に値が入る。 この対
MVPVM パターン
WPF はなんかおかしい、ビヘイビアーといいデータテンプレートセレクターといい、View と ViewModel を両方知らないと達成できないものがそこここにちりばめられている。 特にデータテンプレートセレクターはコントローラ的な性格をもつものだと思っっていた。 SilverlightではテンプレートセレクターがないのでAppのPartialとしてViewModel を初期化してView を切り替えるものを作成し、ビジネスにからデータを取得する機能も便利なので付け加えた。 一方で更新系はViewModel からビジネスを呼ぶほうが断然便利なのでそのルートは確保したままにしている。 これは層を追加することによってアプリケーションファザード的な薄皮をプレゼンターに作る無駄なコーディングが増えることを嫌ったせいだ。 WPFでもその考えを踏襲して作成している。 去年のMSDNマガジンに「WPF 向
MVPVM 設計パターン - WPF 向けのモデル - ビュー - プレゼンター - ビューモデル設計パターン
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 WPF 向けのモデル - ビュー - プレゼンター - ビューモデル設計パターン Bill Kratochvil コード サンプルのダウンロード これまで私が携わり、成功を収めたすべてプロジェクトのうち、もっとも成功を収めたプロジェクトには共通する成果があります。それは、アプリケーションの規模が大きくなるほど、コード ベースが小さくなる、というものです。一見矛盾しているように思えますが、アジャイル環境でコーディングを行うと、コード ベースが小さくなります。要件が変化するにつれて、リファクタリングが行われます。こうしたリファクタリングの際に開発後に明らかになった情報を組み合わせて、既存コンポーネントの再利用効率
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ドキュメントKnockout.js