MVVM-light + RIA サービスのベスト プラクティス [終了]
-
26-09-2019 - |
質問
MVVM-light (RIA サービス付き) のベスト プラクティスのコレクションを開始したいと思います。役立つベスト プラクティスやベスト アプローチであるとわかった項目は数多くありますが、MVVM-light ツールキットを使用している他の人の意見を聞き、彼らが何を発見したかを確認したいと思っています。
この質問への回答としてベスト プラクティスを投稿してください。
解決
MVVM-Lightの基本的な使い方
- App.cs ファイルの Application_Startup 関数で DispatcherHelper を初期化します。
- BaseClass から ViewModel を作成する
- 常に ViewModelLocator クラスを作成します。このクラスにはすべての View Model が含まれ、アプリケーションのリソースにリンクされます。
- RelayCommands を使用して関数をビューに公開する
- DispatchHelper をいつ使用するかを学習します。
クリーンアップのアイデア:
- 必要に応じて、Cleanup() で DomainContext の EntitySet をクリアするために ViewModel に追加します。
- アプリケーションでアクティブに必要でなくなったビューモデルをクリアするには、ViewModelLocator の CleanupSomeVM() 関数を呼び出します。
CleanUp 機能をいつ、どのように使用するかについて他の人から聞きたいです。アプリケーションが成長するにつれて、クライアントのメモリ使用量をより適切に管理するためにいくつかのクリーンアップ関数を追加する必要性を感じます。
ブレンド可能性について:
- サービス/クエリ実装をインターフェイスに抽象化します。
- サービス実装クラスごとに 2 つのクラスを作成します (設計用に 1 つ、運用用に 1 つ)
- 各 ViewModel 内で独自のサービス クラスを実装し (IsInDesignMode を使用)、必要に応じて Blendable Service 実装を作成します。
- 静的変数を使用して、サービス実装クラス内に DomainContext を保持します。
- ViewModel のコンストラクターに DispatcherHelper.Initialize() を追加しますが、これはデザイン モードの場合のみです。Blend はページをロードするときにアプリをロードしませんが、これはそれを回避します。
追加されたビジネス ロジックの場合:
- ビジネス ロジックを最初にモデルに追加し、次に ViewModel に追加します。
- モデルの部分メソッドを使用して、適切な変更/更新イベントのロジックを追加します。
- 読み取り専用プロパティ (ゲッターのみ) を追加して、モデルに概要と計算値を提供します。
ビューの場合:
- 常にルートをロケーター オブジェクトにバインドします。
- コードビハインド ロジックはレイアウトまたはカスタム UI ロジックのみに留めるようにしてください。ViewModel の参照は避けてください。
コレクションの場合:
- ViewModel のコレクションには CollectionViewSource を使用し、DomainContext の EntitySet のソースを使用します。
- すべてのフィルタリング、並べ替え、グループ化ロジックを ViewModel の CollectionViewSource に適用します。
- ServiceCalls の後、必要に応じて CollectionViewSource オブジェクトで .View.Refresh() を呼び出し、UI を更新します。
ViewModel連携用(コントローラーロジック)
- メッセージは慎重に使用してください。複雑すぎると管理が困難になる可能性があります。
- 送受信には、NotificationMessage クラスと PropertyChangedMessage クラスを使用します。
RIA ドメインサービスの場合:
- 更新/挿入/削除ロジックではなく、変更の永続化機能にログを実装します。
- Insert、Update、Delete 関数中に、ナビゲーション プロパティ経由で別のエンティティを参照する必要がある場合は、EntityStatus の競合を防ぐために、最初に EntityStatus を確認するか、別のコンテキストからエンティティをロードします。
デバッグ/テストの場合:
- 出力ウィンドウでバインド エラーを確認し、修正してください。バインディング エラーはユーザーに通知せずに失敗しますが、アプリケーションのパフォーマンスと予期される動作が低下します。
- Silverlight で単体テストを作成して、追加されたモデル/ビジネス ロジックを検証する
- 単体テスト プロジェクトを作成してサーバー側のロジックと機能をテストする
エンティティ フレームワークの場合:
- EntitiesContext とドメイン サービスの 1 対 1 の一致を維持します。これを別の方法で分割しようとすると問題が発生します。
- 挿入、更新、および削除ロジックを慎重に構築するために多くの時間を費やすつもりがない限り、[Composition] 属性を使用しないでください。
- 別のサービスを使用して、カスタム タイプを RIA クライアントに返します。これらを EntityFramework オブジェクトの DomainService に追加しないでください。
- サーバー側の更新/統合ロジック (他のシステムの更新など) は、Insert、Update、Delete 関数ではなく PersistChangeSet 関数で実行します。これにより、ナビゲーション プロパティを介してエンティティを誤って取り込み、切り離されたバージョンが更新されないままになるのを防ぐことができます。
- 追加のコンテキストを作成して、更新/統合ロジック中に現在の値を検索します。
所属していません StackOverflow