4

私が現在取り組んでいるシステムには、インターフェースと基本クラスとして定義されている多くのコンポーネントがあります。システムの各部分には、システムの他の部分と相互作用する特定のポイントがいくつかあります。

たとえば、データ準備コンポーネントは、最終的にデータ処理部分に移動する必要がある一部のデータを準備します。通信コンポーネントは、外部に中継するために、さまざまなコンポーネントのステータスを照会する必要があります。

現在、私は「神オブジェクト」、またはシステムのさまざまな部分についての深い知識を持つオブジェクトを使用して、システムのこれらの部分を接着します。ここでイベントに登録し、結果をあちらのメソッドにシャトルし、ここでコールバックメソッドを作成して、あちらでそのメソッドの結果を返します。特定のアクションがSTAスレッドなどで実行します。

便利ですが、この1つのタイプは、システム内の他のすべての人がどのように設計されているかについて多くのことを知っているのではないかと心配しています。イベント、メソッド、またはコールバックを公開できるインスタンス、またはこれらを消費できるインスタンスを指定できる、より汎用的なハブの方がはるかに望ましいです。

私はリアクティブフレームワークのIObservable/IObserver機能についてもっと見てきましたが、それは.NET 4.0に組み込まれています(私は信じています)。

このパターンを利用して、「神オブジェクト」を置き換えることはできますか?どうすればこれを行うことができますか?この特定の目的のためにこのパターンを使用するためのリソースはありますか?

4

1 に答える 1

1

神オブジェクトをMSDNがここで説明しているものに置き換えることができるようです。

Microsoft StreamInsightプラットフォームを使用して複合イベント処理(CEP)アプリケーションを作成するには、イベントを定義する構造、イベントを生成および消費するオブジェクト、およびイベントの処理に必要なビジネスロジックを含むクエリテンプレートを作成します。

私たちのチームは、すぐに.Net 4.0に移行する予定はありません(残念ながら)。そこで、MAF / MEFが提供するものに似たカスタムフレームワークを構築することで、神オブジェクトのシナリオを回避しました。これにより、Microsoftがアダプターと呼ぶものを使用して分散ナレッジベースが作成されました。各アダプターは、それ自体のモジュール、データ、イベントなどの受け渡しのみを担当します。データとイベントを受け取り、処理し、それぞれのアダプターに戻す共通のオペレーターがあります。

私の理解とIObservableは、神オブジェクトIObserverは必要ないだろうと信じるのに役立ちます。事実上、さまざまな部分で何が起こっているかについての分散知識ベースを作成します。これらのインターフェースの明らかな利点は、中間コミュニケーター(つまりアダプター)が不要になることでもあるようです。したがって、知識の分散は実際にはIObservable派生クラスにあります。このモデルは本質的に話者/応答者の関係を導き出します-調停/仲裁クラスはありません。

于 2010-02-16T18:33:56.617 に答える