タグ付けされた質問 「mvvm」

Model View View-Modelは、イベント駆動型プログラミング、特にXAMLおよび.NET言語を使用する.NETプラットフォーム上のWindows Presentation Foundation（WPF）およびSilverlightをサポートするUI開発プラットフォームをターゲットとしてMicrosoftによって開発されました。それ以来、Angular、Knockout、ExtJSなどの多くのJavascriptフレームワークがこのパターンを採用しています。 ほとんどのソフトウェアパターンと同様に、MVVMには適切な用途と悪用があります。MVVMの使用はどのような条件下で適切ですか？いつお勧めしませんか？

47 wpf  mvvm  silverlight  angularjs  xaml 

例＃1：MVVMアプリケーションにビューが表示され（ディスカッションの目的でSilverlightを使用しましょう）、新しいページに移動するボタンをクリックします。 例＃2：同じビューに別のボタンがあり、クリックすると、子ウィンドウ（ダイアログ）に詳細ビューが開きます。 ユーザーのクリックに応答するメソッドを持つボタンにバインドされたViewModelによって公開されるCommandオブジェクトがあることを知っています。しかし、それではどうでしょうか？どうすればアクションを完了できますか？いわゆるNavigationServiceを使用していても、何を伝えているのでしょうか？ 具体的には、従来のビュー優先モデル（WebやSL組み込みナビゲーションフレームワークなどのURLベースのナビゲーションスキームなど）では、Commandオブジェクトは次に表示するビューを知る必要があります。パターンによって促進される懸念の分離に関しては、これは境界線を越えるようです。 一方、ボタンがCommandオブジェクトに接続されておらず、ハイパーリンクのように動作する場合、ナビゲーションルールはマークアップで定義できます。しかし、ビューでアプリケーションのフローを制御し、ナビゲーションは単なる別のタイプのビジネスロジックではありませんか？（場合によってはyes、その他の場合はnoと言うことができます。） 私にとって、MVVMパターンのユートピア実装（および他の人がこれを公言していると聞いたことがあります）は、アプリケーションがヘッドレスで実行できるように（つまり、ビューなし）ViewModelを配線することです。これにより、コードベースのテストに最も広い領域が提供され、ビューがアプリケーションの真のスキンになります。そして、私のViewModelは、メインウィンドウ、フローティングパネル、または子ウィンドウに表示されるかどうかを気にするべきではありませんか？ このアプローチによると、各ViewModelに表示するビューを「バインド」するのは、実行時に他の何らかのメカニズムに依存します。しかし、ビューを複数のViewModelと共有したい場合、またはその逆の場合はどうでしょうか？ したがって、View-ViewModel関係を管理する必要があるため、子ウィンドウ/ダイアログの表示など、ビュー間をナビゲートする必要がある場合に何を表示するかを知るために、MVVMパターンでこれをどのように実現しますか？

33 design-patterns  silverlight  mvvm 

私はかつてMVVM / WPFプロジェクトを開始しました。このプロジェクトは最終的に構築および展開され、そのためにCaliburn.Micro MVVMフレームワークの多くを学びました。実際のところ、私はそのためにCaliburn.Microを使用せず、自分でMVVMの概念をいくつか実装しました（具体的には、ViewModelBaseとRoutedCommandクラスのみ）。 今、私は同じ行に沿ってやや大きなプロジェクトに割り当てられました：「シングルユーザーリッチクライアントオフラインデスクトップアプリケーション」、と言うことで、私はCaliburn.Microを使用することにしました。それが私の「問題」の始まりです。 私はこの有名なブログ記事で、タイトルに「MVVMを使用している場合、フレームワークが必要」と書かれています。 「フレームワークなしでMVVMのようなことをしようとすると、膨大な作業が必要になります。大量のコードを複製し、車輪を再発明し、考え方を変えるように人々を再訓練します。 少なくともフレームワークを使用すれば、コードの重複を避け、できれば車輪を再発明する必要がなく、人々の再訓練に集中できるようになります。通常、再トレーニングの部分は避けられませんが、フレームワークは配管コードと構造を提供し、プロセスを容易にします。」 最初に読むことに同意しますが、実際のアプリケーションでのCaliburn.Micro（CM）での実際の経験は、無知で見当識障害です。つまり、フレームワークはプロセスをまったく簡単にしませんでした。まったく逆です。むしろ、（あまりにも）非公式マニュアルにロブ・アイゼンバーグが提供する絶えず繰り返し実施例を読むこと、そして物事が動作するように設計されているように見える畳み込まれて、サンプル、およびその全く間接的なクラスとインタフェースの関係から、使用パターンを推測しようとしているベースの上を副作用は、あなたがベテランの天才でない限り、人間的には不可能だと思われます（暴言はごめんなさい。 任意の上記の些細なシナリオことは言うまでもありません私が働いたことがない何かである、IoCコンテナを伴うように思われ、どのように見える私も持っていないかもしれない問題を解決。私の問題やアプリケーションの領域について考えるのではなく、これらのことを学ぶためにプロジェクトにもっと時間を費やすつもりはありません。バナナが欲しかったのですが、CMはバナナのバスケットを持ったゴリラ（IoC）をくれました。 私が実際に実装したい少数のMVVM固有のクラスのみで構成される自作MVVMフレームワークに戻ることを検討しているので、ここで何かを失った場合に備えて、少なくともCMにチャンスを与えたいと思います。まったくの未経験と無知から「間違った方法で」物事を行うだけです。そして質問は次のとおりです。 「フレームワークは物事をより簡単に、より自然にする」というコンセンサスが広まっていますが、もし私がまったく逆になっているのであれば、フレームワークを使うべきではないということですか、それとも間違った方法で学習しようとしていますか？そもそもフレームワークを使用するべきではないという手がかりはありますか？または、単純なMVVM開発でCMを使用する方法を理解するための「正しい」方法はありますか

28 frameworks  wpf  mvvm 

私は次の技術環境でプロジェクトを開始しています：.Net 4.0、Entity Framework 4.0、WVM with MVVM Architecture 私はネット上で多くの例を見て、この環境に関する本をいくつか見ました。いくつかの例では、著者はこのアイデアを持っていました： Viemodelには、Modelクラスのインスタンス（Entity Framework Entity、Personなど）があります WPFビューコントロールをModelのプロパティにバインドします 一部の著者はそうしましたが： Viemodelは、モデルのすべてのプロパティを公開します。 モデルに直接ではなく、ViewModelのプロパティにWPFビューコントロールをバインドします。 それでは、viewmodelが独自のモデルを公開するのではなく、モデルからプロパティをバインドできるようにすることをお勧めしますか？またはどちらがより好ましいですか？

21 .net  entity-framework  mvvm 

私はウェブの世界でReduxとReactについて学び始めましたが、それについて学べば学ぶほど、WPFのMVVMスタイルのアーキテクチャ（特にビューをバインドするためにCaliburnを使用して） ViewModelsへ）。 Reduxには、状態の管理方法を指示するいくつかの簡単な原則があり、UIの更新、イベント処理、状態の変更をより予測可能にします。原則は次のとおりです。 単一の真実のソース（すべての可変状態は単一の共有オブジェクトに格納されます）。 状態は読み取り専用です。コード全体でコンポーネントによって変更することはできません。これは通常、WPFで発生することです。 状態は、純粋な関数によってのみ変更できます。 WPFのMVVMアーキテクチャを使用すると、インタラクティブビューを非常に迅速に構築できますが、さまざまなビューモデルやイベントがすべて状態を変更する場合のデバッグの問題は悪夢です。たとえば、ビューを変更してデフォルトのタブを設定しようとしたイベントが発生しましたが、Webサービスからのデータの非同期読み込みが完了していないため、タブはまだ存在しないため、何も起こりません 相互に更新する相互に関連するviewModelsコンポーネント間の複雑な相互作用を理解するために、私は何時間も図を描きました。 Reduxは、この状態の予測不可能性の一部を解決することを目指していることを理解しています。状態の管理を改善するために、WPFにうまく適合する類似の何か、またはアーキテクチャパターンがありますか？Reduxの原則が.NETでどの程度うまく機能するかは、まだ試していませんのでわかりません。おそらく誰かがいくつかのアドバイスを与えることができるいくつかの経験を持っていますか？

21 wpf  mvvm  state  redux 

多数の値の変換を必要とするビューを持つWPFアプリケーションに取り組んでいます。当初、私の哲学（XAML Disciplesに関するこの活発な議論に一部影響を受けました）は、ビューのデータ要件のサポートについて厳密にビューモデルを作成することでした。つまり、データを可視性、ブラシ、サイズなどに変換するために必要な値の変換は、値コンバーターと多値コンバーターで処理されます。概念的には、これは非常にエレガントに見えました。ビューモデルとビューの両方に明確な目的があり、うまく分離されます。「データ」と「外観」の間に明確な線が引かれます。 まあ、この戦略を「古い大学の試み」にした後、私はこの方法で開発を続けたいかどうか疑問に思っています。私は実際に、値コンバーターをダンプし、（ほとんど）すべての値変換の責任をビューモデルの手に直接置くことを強く考えています。 値コンバータを使用する現実は、明確に分離された懸念の見かけの価値まで測定しているようには見えません。値コンバーターの最大の問題は、使用するのが面倒なことです。新しいクラスを作成し、実装するIValueConverterかIMultiValueConverter、値をobject適切な型にキャストし、DependencyProperty.Unset（少なくとも多値コンバーターの場合）テストし、変換ロジックを記述し、コンバーターをリソースディクショナリに登録する必要があります [下記の更新を参照]、最後に、かなり冗長なXAMLを使用してコンバーターを接続します（バインディングとコンバーターの名前の両方にマジックストリングを使用する必要があります）[以下の更新を参照]）。特にVisual Studioのデザインモード/ Expression Blendでは、エラーメッセージはしばしば不可解であるため、デバッグプロセスもピクニックではありません。 これは、すべての価値変換を担当するビューモデルを作成するという代替策が改善であると言っているわけではありません。これは、草が反対側でより緑であるという問題である可能性が非常に高い。関心事のエレガントな分離を失うことに加えて、派生プロパティの束を記述し、RaisePropertyChanged(() => DerivedProperty)ベースプロパティを設定する際に慎重に呼び出す必要があります。これは、不快なメンテナンスの問題であることがわかります。 以下は、ビューモデルに変換ロジックを処理させ、値コンバーターを廃止することの長所と短所をまとめた最初のリストです。 長所： マルチコンバーターが排除されるため、総バインディング数が少なくなります 少ないマジックストリング（バインディングパス+コンバーターリソース名） 各コンバータを登録する必要はありません（さらにこのリストを維持します） 各コンバーターを作成する作業が少なくなります（インターフェイスの実装やキャストは不要） 変換に役立つ依存関係を簡単に挿入できます（例：カラーテーブル） XAMLマークアップは冗長ではなく、読みやすい コンバーターの再利用は引き続き可能です（ただし、ある程度の計画が必要です） DependencyProperty.Unsetに不可解な問題はありません（複数値コンバーターで気づいた問題） *取り消し線は、マークアップ拡張機能を使用すると消える利点を示しています（以下の更新を参照） 短所： ビューモデルとビューの間のより強い結合（たとえば、プロパティは可視性やブラシなどの概念を処理する必要があります） ビュー内のすべてのバインディングの直接マッピングを可能にする、より多くのプロパティ RaisePropertyChanged派生プロパティごとに呼び出す必要があります（以下の更新2を参照） 変換がUI要素のプロパティに基づいている場合、コンバーターに依存する必要があります おそらくおわかりのように、この問題については胸焼けがあります。私は、リファクタリングの道を進むのを非常にためらっていますが、値変換を使用するか、ビューモデルで多数の値変換プロパティを公開するかどうかにかかわらず、コーディングプロセスが同じように非効率的で退屈です。 賛否両論ありませんか？価値変換の両方の手段を試した人にとって、あなたにとってどちらがより効果的であると思いましたか？他の選択肢はありますか？（弟子たちは、タイプ記述子プロバイダーについて何かを言及しましたが、彼らが話していることを理解できませんでした。これについての洞察はありがたいです。） 更新 本日、「マークアップ拡張機能」と呼ばれるものを使用して、値コンバーターを登録する必要をなくすことができることを発見しました。実際、これらを登録する必要がなくなるだけでなく、を入力しConverter=たときにコンバーターを選択するためのインテリセンスが実際に提供されます。：ここでは私が始まった記事ですhttp://www.wpftutorial.net/ValueConverters.htmlが。 マークアップ拡張機能を使用する機能により、上記の長所と短所のリストと議論のバランスが多少変わります（取り消し線を参照）。 この啓示の結果として、私はハイブリッド私がコンバータを使用するシステムで実験てるBoolToVisibilityと私は呼んでMatchToVisibility、他のすべての変換のためのビューモデル。MatchToVisibilityは基本的に、バインドされた値（通常は列挙型）がXAMLで指定された1つ以上の値と一致するかどうかを確認できるコンバーターです。 例： Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}" 基本的にこれは、ステータスが終了またはキャンセルのいずれかであるかを確認します。そうである場合、可視性は「可視」に設定されます。それ以外の場合、「非表示」に設定されます。これは非常に一般的なシナリオであることが判明し、このコンバーターを使用すると、ビューモデルの約15個のプロパティ（および関連するRaisePropertyChangedステートメント）が節約されました。を入力するとConverter={vc:、「MatchToVisibility」がインテリセンスメニューに表示されることに注意してください。これにより、エラーの可能性が著しく減少し、値コンバーターの使用が面倒になりにくくなります（必要な値コンバーターの名前を覚えたり検索したりする必要がなくなります）。 興味があれば、以下のコードを貼り付けます。この実装の一つの重要な特徴は、MatchToVisibilityそれがバインドされた値であるかどうかをチェックしていることでenum、それがあれば、それはチェックを確認するためにValue1、Value2なども同じ型の列挙型です。これにより、列挙値のいずれかが誤って入力されているかどうかの設計時および実行時チェックが提供されます。これをコンパイル時のチェックに改善するには、代わりに以下を使用できます（手で入力したので、間違えた場合はご容赦ください）： Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue={x:Type {win:Visibility.Visible}}, IfFalse={x:Type {win:Visibility.Hidden}}, …

20 silverlight  wpf  mvvm  xaml 

次のシナリオのビューモデルの作成にヘルプが必要です。 深い階層データ 同じデータセットの複数のビュー 各ビューは、アクティブな選択に基づいて、動的に変化する単一のビューです プロパティの値に応じて、タブコントロールにさまざまな種類のタブを表示する 私の質問： 各ビュー（VM1、VM2など）のビューモデル表現を作成する必要がありますか？ 1. Yes: a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1) b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes) 2. No: a. Do I use a huge, single view model that caters for all views? これが単一のビューの例です …

18 wpf  mvvm 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は現在、WPF用のMVVMに頭を回そうとしています-私は頭を概念に回すつもりはありませんが、愚かなCRUDよりもbeatられたトラックから遠く離れていることの実際の要点についてです。 私が気づいたのは、多くのフレームワークであり、ほとんど/すべてのブログ投稿は「年齢」前のものです。 これは、古い帽子でブロガーが次のビッグシングに移行したからか、それとも言うべきことをすべて言ったからでしょうか。 言い換えれば、私はここに欠けているものがありますか？

18 wpf  mvvm 

私は長い質問に謝罪します、それは少し暴言として読みますが、そうではないと約束します！私の質問を以下にまとめました MVCの世界では、物事は簡単です。モデルには状態があり、ビューにはモデルが表示され、コントローラーはモデルとのやり取り（基本的に）を行い、コントローラーには状態がありません。作業を行うために、コントローラーはWebサービス、リポジトリー、その他多くに依存しています。コントローラーをインスタンス化するとき、これらの依存関係を提供することに関心があります。アクション（コントローラーのメソッド）を実行するとき、これらの依存関係を使用してモデルを取得または更新するか、他のドメインサービスを呼び出します。一部のユーザーが特定のアイテムの詳細を表示する場合など、コンテキストがある場合、そのアイテムのIDをパラメーターとしてアクションに渡します。コントローラーのどこにも、状態への参照はありません。ここまでは順調ですね。 MVVMと入力します。WPFが大好きで、データバインディングが大好きです。ViewModelsへのデータバインディングをさらに簡単にするフレームワークが大好きです（Caliburn Micro atmを使用）。しかし、この世界では物事はそれほど簡単ではないと感じています。もう一度練習してみましょう。モデルには状態があり、ビューには ViewModel が表示され、ViewModelには（基本的に）モデルとのやり取りがあり、ViewModelには状態があります。するには、（1つ以上のモデルに、多分それ委譲し、すべてのプロパティを、それ手段は、それ自体の状態をあるモデルの1の方法または別の、への参照を持っている必要があります明確にするために）行いますViewModelには、Webサービス、リポジトリ、その他多くの依存関係があります。ViewModelをインスタンス化するとき、それらの依存関係だけでなく状態も指定する必要があります。そして、これは、紳士gentle女の皆さん、私をいらいらさせます。 あなたはインスタンス化する必要があるときProductDetailsViewModelからProductSearchViewModel（そこからあなたが呼び出されるProductSearchWebService順番に返されIEnumerable<ProductDTO>、あなたはこれらの事の1行うことができますか？私と一緒に、まだ、誰も）： call new ProductDetailsViewModel(productDTO, _shoppingCartWebService /* dependcy */);、これは悪いです、さらに3つの依存関係を想像してください。これは、ProductSearchViewModelそれらの依存関係も同様に引き受ける必要があることを意味します。また、コンストラクタを変更するのは苦痛です。 call _myInjectedProductDetailsViewModelFactory.Create().Initialize(productDTO);、ファクトリは単なるFuncであり、ほとんどのIoCフレームワークによって簡単に生成されます。Initメソッドは漏れやすい抽象化であるため、これは悪いと思います。また、Initメソッドで設定されているフィールドにreadonlyキーワードを使用することもできません。他にもいくつかの理由があると思います。 call _myInjectedProductDetailsViewModelAbstractFactory.Create(productDTO);So ...これは、このタイプの問題に通常推奨されるパターン（抽象ファクトリー）です。でも、実際に使い始めるまでは、静的型付けへの渇望を満たすため、天才でした。定型コードの量は多すぎると思います（私が使用するとんでもない変数名は別として）。ランタイムパラメーターを必要とする各ViewModelについて、2つの追加ファイル（ファクトリーインターフェースと実装）を取得し、4回の追加時間などの非ランタイム依存関係を入力する必要があります。また、依存関係が変更されるたびに、ファクトリーでも依存関係を変更できます。私はもうDIコンテナさえ使用していないように感じます。（Castle Windsorにはこれに対する何らかの解決策があると思います（それ自体の欠点があるため、間違っている場合は修正してください））。 匿名型または辞書で何かをする。私は静的型付けが好きです。 ええ このように状態と動作を混在させると、MVCにはまったく存在しない問題が発生します。そして、私は現在、この問題に対して本当に適切な解決策がないと感じています。今、私はいくつかのことを観察したいと思います： 人々は実際にMVVMを使用しています。したがって、彼らは上記のすべてを気にしないか、他の素晴らしい解決策を持っています。 WPFを使用したMVVMの詳細な例は見つかりませんでした。たとえば、NDDDサンプルプロジェクトは、DDDの概念を理解するのに非常に役立ちました。誰かがMVVM / WPFの似たような方向性を教えてくれたら、とても気に入っています。 MVVMをすべて間違っているのかもしれませんが、デザインを上下逆にする必要があります。たぶん、私はこの問題を全く抱えるべきではないでしょう。他の人が同じ質問をしているのは知っているので、私だけではないと思います。 要約する ViewModelが状態と動作の両方の統合ポイントであることは、MVVMパターン全体のいくつかの問題の原因であると結論付けるのは正しいですか？ 静的に型付けされた方法でViewModelをインスタンス化するための唯一/​​最良の方法は、抽象ファクトリパターンを使用していますか？ 詳細なリファレンス実装のようなものはありますか？ 状態/動作の両方を備えたViewModelがたくさんあるのは、デザインの匂いですか？

17 c#  design  wpf  mvvm 

私はVSでアプリケーションの構造を設定しようとしていますが、合理的なレベルに「試して」将来的に証明したいと思います。このアプリケーションは、慣例に従わなかった古いWinformアプリをWPFで書き直したものです。レイヤー、ティア、頭字語などはありません... これはかなり大規模なエンタープライズアプリケーションです。私のDBがそうであるように、Linq To SQLを使用する予定であり、ほとんどの場合、常にMS SQLになります。また、既存のスキルセットがあります。 できる限りMVVMとDDDをフォローしたいのですが、これらを組み合わせるとアプリケーションの構造が混乱します。いくつかの例を使って説明してみましょう。 MVVMに従うと、フォルダー構造は次のようになります。 Views Models ViewModels Helpers しかし、私のプロジェクト構造がこれに似ているかもしれない単純化されたDDD階層化アプローチにどのように適合しますか： MyApp.UI MyApp.Domain MyApp.Data Modelsドメインレイヤーに配置するのPersonですか、それともsayの3つのバージョンがありますか？これは、リポジトリとDBオブジェクトのドメインオブジェクトへのマッピングをどこに配置するかという別の質問につながりますか？私はデータを仮定します... Views私はUIに行くだろうが、ViewModelsまただろうか？ 最後に、ビジネスロジックをどこに埋め込むか。 CodePlex、DDD Exampleで以下を見つけましたが、いくらか助けになりましたが、Webアプリのように思えますが、それは問題ではなく、私の無知が輝いています。 誤解しないでください。フォルダをいくつでも持つことができ、好きな名前を付けることができます。私は、これらの場所が必ずしも呼ばれているものではなく、これがスケーラブルになるように、物を置く場所を見つけようとしています。 私の質問の核心はこのように示されるかもしれません。によって生成されたオブジェクト がありtblPersonます*.dbml。これは明らかであり、「データ」レイヤーに属します。 これで、Model、DTO、Domain Model、またはと呼ばれる別のLayer（project？）で呼び出されるものがありPersonます。私はどこに置くべきかわからないことのMapperためPersonに必要になるでしょうtblPerson。 次に、ViewModelをEditPerson取得しPersonます。たとえば、それから取得する独自のプロパティがありますが、それ以上の場合もあります。 最後に、そのViewModelにバインドされたビューがあります。 その段落が私の仮定と推測で満たされていることを明確にするために、誰かが私のために空気をきれいにするのを手伝うか、そこから洞察を提供してくれることを望んでいます。

17 .net  wpf  mvvm  domain-driven-design  project-structure 

最初のWPFアプリケーションを作成しようとしており、MVVMパターンに精通しています。私たちは多くのWinformアプリケーションを構築しており、非常に成功したアーキテクチャを持っています。そのアーキテクチャを翻訳したり、アーキテクチャの特定の部分がMVVMモデルに適合する場所を決定したりするのに少し苦労しています。 歴史的には、BusinessLogic dllと通信するGui（メインexe）があります。BusinessLogicはWebサービスを介してDAL dllと通信し、DALはDBと対話します。DAL、BusinessLogic、およびGUIはすべて同じBusinessObjects dllを参照します。 MVVMへの移行の一部はかなり単純です。Guiにはビューが含まれ、BusinessOjbectsにはモデルが含まれ、DALはDBと対話します（ただし、それらを実装するテクノロジーは変更される可能性があります）。 わからないのは、BusinessLogicコンポーネントです。歴史的には、これはビューのコントロールを呼び出すためにGUIに呼び出す関数を提供していました（つまり、Customerオブジェクトのリストまたは典型的なCRUD関数を返すGetCustomerList）。 主な問題は、MVVMパターンがViewModelを格納するために追加のコンポーネントを必要とするのか、単に考え方を変えてBusinessLogicコンポーネントとして使用したものをViewModelに移行するだけなのか、ということです。 BusinessLogicコンポーネントはViewModelを表しますか？

15 architecture  mvvm 

モデルビューコントローラー、モデルビュープレゼンター、モデルビューViewModelなどについて読んでいますが、一般的に、基本的な概念は非常に理解しやすいようです。可能。デザインチョコレートにロジックピーナッツバターは含まれていません。クール、私はそれが好きです。 問題は、その3番目の部分についてはまだ少し曖昧だということです...モデルまたはビューではありません。誰もがそれを何と呼ぶべきか、何をすべきか、何が適切で、何が間違っているのか、自分の考えを持っているようです...それはプレゼンターの仕事だからです。 私はとりとめのないです。 それらの違いを誰かに説明するように頼むのではなく、すでに何度も行われているので（私は知っています;数え切れないほど多くの記事を読んでいます）-私は私は自分でモデルを作った少数のプログラマーです。 そうは言っても、このデザインをどのように分類しますか？そしておそらくもっと重要なことですが、これについて明らかに悪いことはありますか？確かに、これが本当に堅実な設計であれば、私は良いことをしていると聞きたいと思いますが、賞賛よりもむしろ堅実なアドバイスを与えられるでしょう。 注：Model-View-の神秘的な3番目の部分に「ブリッジ」を使用しますか？それが「すべき」であるという潜在意識の提案を避けるため。 モデル データに対する権限です。 リクエストされた変更に関する情報をブリッジから受け取ります。 データが他のデータにどのように関連するかについてのすべてのロジックを含み、実行します。 データが変更されたときにブリッジに通知します（ブリッジが関心を示したデータについて）。表現の編集：外部のサブスクライバー（何も知らない）が、その状態または計算結果をモニターできるようにします。 ビューに関する知識がありません。 見る ユーザーにデータを表示および操作する方法を提供することに関心があります。 ブリッジからデータ更新に関する情報を受け取ります。 ユーザーにデータとコントロールを提示する方法のすべてのロジックを含み、実行します。 ユーザーがモデルに（おそらく）影響を与えるアクションを実行したときに、ブリッジに通知します。 興味のある情報をブリッジに通知します。 モデルに関する知識がありません。 ブリッジ モデルとビューの間のコーディネーターおよびトランスレーターです。 モデルとビューの間で受け渡される情報に適切なフォーマット変更を加えます。 「誰が何を知る必要があるか」に関する情報を保持します。 モデルとビューの両方の知識がある。 その他の注意事項 より複雑なプログラムでは、複数のモデルが存在するのが一般的です。この状況では、ブリッジは通常、複数のモデル間の調整/翻訳の仕事を引き受けるため、protocall / API / designモデルの構築対象の権限になります。（たとえば、カードゲームプログラムを構築し、代替のデッキシャッフルモデルを構築する場合、ブリッジを使用して、ブリッジとの適切な通信に必要な機能を決定する必要があります。） ビューとモデルが1つだけの小さな単純なプログラムでは、ブリッジがどちらの側でどの機能を使用できるかを「想定」するのが一般的です。ただし、プログラムがより複雑になると、非効率性とバグのある仮定を回避できるように、ビューとモデルが機能をブリッジに報告することをお勧めします。 ほぼカバーしていると思います。どうしても、私が使用する傾向のあるデザインについて質問がある場合は歓迎します。また、提案をお勧めします。 そしていつものように、お時間をいただきありがとうございます。

14 design-patterns  mvc  mvvm  mvp 

彼の本「Clean Architecture」で、叔父ボブは、プレゼンターが受け取ったデータを「表示モデル」と呼ぶものに入れるべきだと言っています。 これは、Model-View-ViewModel（MVVM）設計パターンの「ViewModel」と同じものですか、それとも単純なデータ転送オブジェクト（DTO）ですか？ 単純なDTO ではない場合、ビューにどのように関連しますか？ビューは、オブザーバー関係を通じて更新されますか？ 私の推測では、彼の本の第23章でロバート・マーティンは次のように述べているため、MVVMのViewModelに似ていると思います。 [The Presenter's]ジョブは、アプリケーションからデータを受け取り、プレゼンテーション用にフォーマットして、Viewがデータを画面に簡単に移動できるようにすることです。たとえば、アプリケーションでフィールドに日付を表​​示する場合、プレゼンターにDateオブジェクトを渡します。プレゼンターは、そのデータを適切な文字列にフォーマットし、Viewモデルと呼ばれる単純なデータ構造に配置します。Viewモデルでは、データを見つけることができます。 これは、たとえばDTOの場合のように、単に関数引数として受け取るのではなく、Viewが何らかの方法でViewModelに接続されていることを意味します。 あなたは、画像を見れば、プレゼンターはビューモデルを使用しますが、ので、私はこれを考えるもう一つの理由はありませんビューを。一方、プレゼンターは出力境界と出力データDTOの両方を使用します。 DTOでもMVVMのViewModelでもない場合は、それが何であるかを詳しく説明してください。

13 architecture  mvvm  dto  plugin-architecture  view 

MVVMパターンを使用してWPFアプリケーションを構築しています。現在、私のビューモデルは、サービスレイヤーを呼び出してモデルを取得し（ビューモデルとは無関係です）、モデルをビューモデルに変換します。コンストラクター注入を使用して、必要なサービスをビューモデルに渡します。 簡単にテストでき、依存関係の少ないビューモデルでうまく機能しますが、複雑なモデルのviewModelを作成しようとするとすぐに、多くのサービスが挿入されたコンストラクターがあります（各依存関係と使用可能なすべての値のリストを取得するためのもの）たとえば、itemsSourceにバインドします）。そのような複数のサービスをどのように処理し、簡単にユニットテストできるビューモデルがまだあるのか疑問に思っています。 私はいくつかの解決策を考えています： 使用可能なすべてのサービスをインターフェイスとして含むサービスシングルトン（IServices）を作成します。例：Services.Current.XXXService.Retrieve（）、Services.Current.YYYService.Retrieve（）。そうすれば、大量のサービスパラメータを含む巨大なコンストラクタはありません。 viewModelによって使用されるサービスのファサードを作成し、このオブジェクトを私のviewmodelのctorに渡します。しかし、その後、複雑なビューモデルごとにファサードを作成する必要があります。 この種のアーキテクチャを実装する「正しい」方法は何だと思いますか？

13 architecture  dependency-injection  mvvm 

私のWPFアプリケーションで、新しいビューを作成します。ViewModelまたはModelのどこでそれを行うべきですか？ アプリケーションは（今のところ非常にシンプルです）、1つの「送信」ボタンを備えた1ウィンドウフォームのようなツールです。チェックボックスの1つが選択されている場合、同じViewModelを使用する新しいウィンドウがポップアップし、追加の詳細をユーザーに尋ねます。この質問の目的のために、表示/非表示のパネルなどの別のアプローチを考慮せずに、新しいウィンドウのアプローチのみを検討してみましょう。 理想的には、Viewにはコードがないはずです。さらに、Viewにはロジックが含まれていないため、VMは最初に新しいビューの作成が必要かどうかを確認する必要があり、必要な場合はこの責任をViewに戻して、コードの膨張につながります。 一方、ViewModelで新しいビューを作成すると、ViewModelがViewについて何も認識してはならないという原則に違反します。 では、ViewまたはViewModelで新しいビューを作成する方が良いでしょうか？

11 c#  design  wpf  mvvm