問題タブ [view-model-pattern]

私はMVCフレームワーク（ASP.NET MVC2 / 3 / Razor）を使用して数か月しか経っていないので、本当に楽しんでいますが、ビューモデルの標準を理解するのに苦労しています。私のプロジェクトには、Modelsフォルダー（データモデルが含まれています-Linq DBML、Repository [ies]、Extensionメソッド）とModels/ViewModelsフォルダーがあります。私のビューモデルは通常、再利用可能なクラスであり、通常、特定のビューにアクセスする必要があるLINQオブジェクトまたはオブジェクトのコレクションの単純なget/setプロパティが含まれています。

今私が抱えている問題は、ビューモデルをいつ作成するかを理解することです。私の目標は、特に編集アクションの場合に、LINQオブジェクトをビューモデルとしてできるだけ頻繁に使用することです。私の問題は、表示目的でのみ使用したい他のデータがある場合はどうなりますか？ViewData / ViewBagコレクションを使用するのは好きではありません。これらのメンバーにアクセスするには、コレクションアイテムのキーに関する知識が必要です（デザイナー/フロントエンドの人が「推測」するのは簡単ではありません）。また、ビューごとにViewModelを作成するというアイデアも好きではありません。これは、不必要に厄介なコードのように見えるためです。

たとえば、ある従業員のデータモデルがあり、その従業員とは関係のない情報を表示したいとします。たとえば、サイト統計、動的メニューなど、データベースから取得できると思われる情報をすべて表示します。/ Employee / Editアクションを渡す必要があるモデルは何ですか？残りのViewData[]の束を持つEmployeeオブジェクト、またはカスタムEmployeeView？

ゴールドスタンダードはありますか？私は何が欠けていますか？私が調べなければならないことをあなたは何を変えていますか？前もって感謝します！

MVVMアプリケーションを実行するとき、私は通常、サービスロケーターパターンで動作する中央のViewModelロケーターを持っています。これにより、Ninjectを介してサービスでViewModelを注入できます

私のViewModelロケーターは通常次のようになります。

今、私は「注文」と呼ばれる別のモジュールを追加することを考えています。だから私はOrderViewModel（または実際にはそれらのいくつか）を持っています。そして、それらを分離してMEF経由でインポートしてもらいたいと思います。

このアプローチを拡張/変更して、中心のビューモデルロケーターとインポートされたビューモデルおよびビューを操作できるようにするにはどうすればよいですか。

ええ、私はプリズムとカリバーンを知っていますが、アプローチを見るのは私にとってストレスになるでしょう...

助けてくれてありがとう....

私はMVCを初めて使用します。

MVCでビューモデルを処理する3つの方法を詳しく説明したこの短いビットを読みました。

http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

その要点は私には次のように思われます。

方法1、データベースからオブジェクトを引き出し、それをビューモデルとして使用します。すばやく簡単ですが、複数のテーブルからのデータが必要な場合は、完全に失敗します（方法2がないと回避方法は考えられません）。

方法2、複数のオブジェクトへの参照を持つクラスを作成し、これをビューモデルとして使用します。このようにして、必要なものすべてにアクセスできます。記事によると、ビューが複雑になると、ドメイン/ビューモデルオブジェクト間のインピーダンス不整合が原因で故障します...これが何を意味するのかわかりません。グーグルインピーダンスの不一致は多くのものを返しました。オブジェクトを使用してデータベースのものを表現しているということの要点であり、ものはきれいにマッピングされませんが、おそらく方法1でもこの問題が発生します。私が何であるかわからないない。また、必要なデータを取得するためにビューごとにクラスを作成することは、メンテナンスの観点からは理想的ではなく、選択肢があるかどうかはわかりません。

方法3、まだ頭を悩ませていますが、ドメインモデルに接続されていないクラスにbool addAdditionalを追加した場合、チェックボックスの例が方法2で機能しない理由がよくわかりません。方法3は、ドメインのものを直接返すのではなく、特に必要なプロパティを引き出すだけだと言っているようです。これは良いと思いますが、そうする大きなコンストラクターが必要になるため、保守が難しくなりthis.x = domain.xますthis.y = domain.y。

ビルダー、特にインターフェイスが使用される理由がわかりませんが、引き続き作業を続けます。

編集：私はこれが実際には問題ではないことに気づきました、私の質問は、私の考えは正しいですか？

エンティティごとのリポジトリとビューごとのビューモデルを組み合わせて使用​​したい場合、どのように機能しますか?

私が調べることができるウェブサイトのヒントはありますか？誰かが簡単な例を挙げることができますか？

ありがとう

よろしくお願いします！

ViewModel パターンと Entity Framework の Repository パターンを使用する MVC3 アプリがあるとします。

それぞれが複数のエンティティで構成される作成ビューと更新ビューがある場合、データを保存するためのベスト プラクティスは何ですか?

各エンティティのデータをそれぞれのリポジトリに保存する抽象化されたサービス レイヤーを使用して日付を保存する必要がありますか、それともストアド プロシージャを使用してリポジトリにデータを保存する必要がありますか?

私はどんな提案や推奨事項にもオープンです。

前もって感謝します！

クエリをコントローラに配置するべきではないと彼らが述べている多くの記事を読みましたが、他にどこに配置するかがわかりません。

私の現在のコード：

景色：

ビューモデルとクエリを保持し、表示されるべきではないユーザータイプを除外するにはどうすればよいですか？

私が理解できる限り、ビューモデルを使用するとWeb開発を行うことができます. ローカライズされた文字列で必要なプロパティのみを表示するためにこのアプローチを使用できるという意味で、生活はずっと楽になります。また、mvc3 ビュー モデルで jquery 検証などを使用しています。

私のWebアプリケーションで本当のボトルネックが発生しているので、今は疑問です。このようにすべてのオブジェクト（20個）を照会すると

そして、その Property オブジェクトのリストは、このような Property オブジェクトのリストを期待する FromDomainModel である ViewModel に送信されます

現在、私が使用している同じクラスにいます

しかし、このアプローチを使用して、オブジェクトのコレクションをビューモデルに送信し、そこから同じビューモデルが返され、必要なプロパティがほとんどないため、不思議なことに（少なくとも私にとっては）、複数のエンティティの負荷が発生し、継続時間が大幅に増加します。

さらに情報が必要な場合。問い合わせてください。

また、より良い解決策を知っている場合は、共有してください。

更新: ドメイン モデルを使用する場合は 20 個のエンティティが読み込まれ、上記のビューモデルを使用する場合は 67 個のエンティティが読み込まれ、パフォーマンスが大幅に低下します。

私は、MVVMパターンを実装しようとするSurfaceWPFプロジェクトに取り組んでいます。このプロジェクト内で、さまざまなビューモデルにバインドするいくつかのカスタムコントロールを構築しています。

たとえば、設定ビューモデルを持つ設定コントロールがあり、「全体的な」ビューモデルであるメインビューモデルがあります。

surfacewindows.xamlページでは、mvvm-lightのviewmodelロケーターを使用して、datacontextをメインのviewmodelに設定しています。また、surfacewindow.xamlに設定コントロールを追加し、コントロールでdatacontextを設定viewmodelに設定しました。

ここで、両方のビューモデルが相互作用する必要があります。現在のケースでは、設定コントロールの可視性を設定する必要があります。メインビューモデルにブール値（IsSettingsControlVisible）のプロパティがあり、コンバーターを使用してブール値を可視性オブジェクトに変換することにより、コントロールの可視性プロパティにバインドされます。

この問題は、設定コントロールの閉じるボタンをクリックして表示を非表示に設定する必要がある場合に発生します。コントロールのデータコンテキストを設定ビューモデルに設定したため、メインビューモデルにアクセスできません。

これまで考えてきたのは、設定ビューモデルをプロパティとしてmainviewmodelに追加し、設定コントロールからデータコンテキストを削除することです。settingscontrolでは、バインディングをSettingsProperty.Propertyとして使用します。setttingsコントロールからmainviewmodelにもアクセスできます。それは理にかなっていますか？この種の相互作用を行うためのより良い方法はありますか？

これらの相互作用を実現する方法についてのあなたのアイデアを聞くのが本当に好きです。

MVVM で Jason Dolinger のビデオを見終わったところです。ビュー モデルの ICommand プロパティを適切にセットアップして単体テストする方法を明確にしたいと思います。

FooBarCommand ICommandProperty を持つ次の ViewModel クラスを検討してください。

したがって、ViewModel の FooBar 機能を単体テストする場合、testVM.FooBar() を呼び出すか、testVM.FooBarCommand.Execute() を呼び出してコマンドを実行することで、FooBar() を実行できます。どちらが好ましいですか？最終的にビューのボタンは FooBar() メソッドではなく FooBarCommand プロパティにバインドされるため、私は FooBarCommand プロパティのテストに傾いています。

さらに、View は ViewModel ではなく IViewModel にバインドされるため、IViewModel インターフェイスから FooBar() メソッドを完全に省略できるはずです。

22のカテゴリのリストがあり、カテゴリごとに約8つのmenuItemがありますが、ビューモデルはリストの最後のアイテムのみになります。問題がどこにあるのかわからない。
この時点で、問題はビューモデルの設定方法にあると確信していますが、問題がどこにあるのかわかりません。

ViewModels：_