web-dev-qa-db-ja.com

WCFサービスアーキテクチャ(サーバー側)のイベント

問題:これで、クライアントがサーバーにリクエストを送信したときに発生するイベントがいくつかあります。これらのイベントはサーバーで発生し、サービス自体によってサブスクライブされます(サーバー上のサービスは、チャネルではなく単純なオブジェクトとして、つまりクラスのインスタンス化として相互に対話します)。必要に応じてクライアント。

イベントアグリゲーターパターンでは、サブスクライバーとパブリッシャーはお互いに気づいていません。

今、私はこの問題を実装するために必要なオプションを検討しており、イベントアグリゲーターが私の注意を引きました。さらに、明示的に呼び出すことなく、イベントが発生したときに複数のサービスに通知する方法が欲しいです。

編集:

例:現在のセットアップで、3つのサービスX(publisher)、Y(subscriber) and Z(subscriber)があると言います。サービスYの着信要求があります。これはXの前にあります。これは登録済みサブスクライバー(私はctorでイベントにサブスクライブしました)だったので、インスタンス化されてライブサブスクライバーになりました。今度はXのリクエストが送信され、インスタンス化されてイベントを発行します。 But、ただしZもサブスクライバーでしたが、Xがイベントをパブリッシュしたときに生きているインスタンスがありませんでしたが、呼び出しは聞こえませんでした。以下では、可能な解決策を示しましたが、これはサーバーで発生しています。

編集2:

// Service X and Service Y and Service Z are not linked through a channel
// All services are WCF services and client call them through a channel
public class ServiceX{


publi void DoSomeWork(){


MyEventAggregator<MyEvent>.Instance.Publish(Payload);  //Some event is triggered and the subscribers will be notified


//if event aggregator is not used normal call would go like

ServiceY obj=new SerivceY();  // no channel creation

obj.CallSomeMethod(Payload);
}

}

public class ServiceY(){

public ServiceY(){
//subscribers register for event
MyEventAggregator<MyEvent>.Instance.Subscribe(MyHandler,true);  //true is a flag that keeps subscriber ref alive

}

MyHandler(dynamic obj){
//Do work

}

}


public class ServiceZ{
public ServiceZ(){
//subscribers register for event
MyEventAggregator<MyEvent>.Instance.Subscribe(MyHandlerZ,true);  //true is a flag that keeps subscriber ref alive

}

MyHandlerZ(dynamic obj){
//Do work

}

}
public class MyEvent:PubSubEvents<dynamic>{
//from prism library
//My Event
}


public class MyEventAggregator{

//implements singleton that returns the event aggregator instance.

}
//By using event aggregators the there can be multiple subscribers to an event without them knowing about each other

可能な解決策: Prism Event Aggregatorsを使用してイベントをパブリッシュおよびサブスクライブすることはできますが、それ自体が問題を引き起こします。つまり、サブスクライバーを登録しても、それらが以前にインスタンス化された場合にのみ機能しますイベントがトリガーされます(公開されます)。

だから今私は、インスタンス化しながらサブスクリプションを扱うユニティアプリケーションブロック(それが必要かどうかわからない)と一緒にインフラストラクチャモジュールで処理できるイベントが公開されたときに私のサブスクライバーが生きていることを確認する必要があります大量のオブジェクトにはオーバーヘッドがあります

私が知りたかったのは、WCFとPrism Event Aggregatorsを一緒に使用する人を多く見たことがないので、正しい方向に考えていることです(私が知る限り、Prismはほとんどクライアント側フレームワークと見なされています)。

編集3:

ソリューションコード(パブリッシャーの前にサブスクライバーをインスタンス化するため):この依存関係を解決するためにunityを使用できます。たとえば、global.asax.csファイルのapplication_startメソッドで、次のようにします。

IUnityContainer uContainer = new UnityContainer()
   .RegisterType<ISubscriber, ServiceY>("Abc")
   .RegisterType<ISubscriber, ServiceZ>("Xyz");

ISubscriber myInstance = uContainer.Resolve<ISubscriber>("Abc");
ISubscriber myInstance = uContainer.Resolve<ISubscriber>("Xyz");

ここで、すべてのサブスクライバーが拡張され、ISubscriberインターフェイスは次のようになります。

ServiceY:ISubscriber{}

これにより、イベントが発行されたときにサブスクライバーインスタンスが確実に有効になります。

WCFのイベントをどのように処理しますか?

私が持っている他のオプションはありますか?

2

私はこの質問をcodeplexフォーラムに投稿し、Bryan Noyesから answer をもらいました。それは:

Prism pub-subイベントが設計された目的から外れていると思います。これらは、クライアント側で同時にメモリ内にある疎結合コンポーネント用に設計されていますが、それらのクライアント間に結合を導入したくないそれらが通信するためのコンポーネント。 MSMQベース、RabbitMQ、またはService Bus for Windows ServerのService Busキュー(または、これらの行に沿ったその他の多くのオプション)が、キューをオンプレミスまたはクラウドに配置したい場合)。

したがって、サーバー側のイベントに関して言えば、プリズムサブイベントをpubsubeventsにすることはお勧めできません。

1