WPF MVVMアプリケーションのサービスレイヤのObservableCollection

Question

インターネットで見たWPF MVVMアプリケーションの例VMは、外部ライブラリの「古い」イベントを使用するサービスレイヤとやりとりするレイヤ、 HTTPなどを使用してWeb。しかし、私はすべてのM、V、VM、サービス、および他の部品を自分で構築すればどうなりますか？サービス層とビューモデル層との間の相互作用を適切に構築するにはどうすればよいですか？ ObservableCollection<OrderModel>をサービスに入れてビューのビューモデルからそのまま返すことはできますか？これは悪いアプローチと考えられ、より良い選択肢がありますか？

Answer 1

これはもちろん可能です。このようなことを行う主な理由は、複数のWPFアプリケーション間の重複を減らすことです。

ただし、サービスレイヤー/データレイヤーの実装によっては、データベース接続を使用する長時間実行型のサービスである場合があります。 ObservableCollectionsは、サービス層がアプリケーションによって行われた変更を自動的にデータストアに同期させるという観点から魅力的です。ただし、データ自体から生じる変更（つまり、データを作成/変更する他のプロセスへの応答）を伝える場合は、複雑になります。

サービス層は、もはや参照の唯一の所有者ではないため、実際にインスタンスを置き換えることはできません（大規模な変更の場合）。 UIがコレクションに持つすべてのバインディングを解除します。

したがって、1つのインスタンスを最新の状態に保つことに固執します。サービスがデータベースにバインドされている場合、サービス内で長時間実行される監視プロセスをコード化しない限り、ObservableCollectionを最新の状態に保つための唯一の簡単な方法は、データベース接続/コンテキスト（LinqからSqlまたはEFの場合）を開く - そうでなければ関連するオブジェクトなどは取り戻すことができません（すべてのオブジェクトを強制的に読み込まない限り - スケーラビリティではありません）。

あなたの接続を管理できる何らかの管理レイヤーを書くことは可能ですが、避けられないポーリングやSQL Serverの通知に加えて、コードがかなり複雑になる可能性があります。

しかし、それは本当に依存しています - その特定の問題は目を引くものですが、あなたはそのようなことは単に問題ではないアーキテクチャと環境を持っているかもしれません。

あなたがそれを試してみたいと思ったら、私のアドバイスをお読みください。私のために？私はそれについて考えてきました - そして、いくつかのドメインモデルにINotifyPropertyChangedを追加する以外に、アプリケーションには独自のVMがあるという考えに固執します。複数のアプリケーションが同じVMを共有するかもしれませんが、サービス層自体の内部にはありません。

サービスレイヤーは、データとビジネスロジックへのアクセスを、通常はワンショットで提供します。 VMパターンのクラスは、より長い寿命を持つように設計されています。長時間実行されるサービスレイヤーをコーディングしようとすると、非常に難しくなります。特に将来のすべてのアプリケーションで発生するすべての問題を解決してください。必然的に、単一のアプリケーションのみのサービスレイヤー内でコーディングサービスまたはVMタイプを終了させることになります。その場合は、そのアプリケーションのコードベースにも入っている可能性があります。

Answer 2

私はいくつかの理由でそれをしません。彼らはここに文書化されています：Common mistakes with an observable collection

著者は、サービス層でそれらを使用することを含めて、人々がそれらで作るいくつかの間違いを経験します。

Answer 3

ObservableCollectionは、 "observable"アスペクトが関連するポイント（通常はVMがVに何かを公開している）からのみ使用するようにしたいと思います。リストやコレクションのようなより一般的なものに固執するように誘惑されることがあります（特にそうでないものが特に必要な場合を除きます）。いずれにしても、古いIEnumerableに基づいてObservableCollectionを作成するには、VMが十分に簡単です。

特に、ObservableCollectionのSystem.Collections名前空間内の配置は、Microsoftが特別なクラス（と確かにwpf固有のものではない）とは考えていないように思われます。