PRISM and WCF - Do they play nice?

Answer 1

It seems like a complicated approach to the problem.

Are you raising the event from the Client application, or raising the events from the service using the callback contract? or both?

I would approach this with a simple service class in the client. It can implement the Callback contract, and for each callback method it can just raise a Prism event locally to any subscribers in the client. If you need to raise events that are handled by the service, then the service class can subscribe to those events and call the wcf service.

All you need really is a class that abstracts the details of the wcf service away from the client, and exposes it's interface through Prism events.

I personally wouldn't want to modify / extend the infrastructure component and create a dependency on the concrete wcf service.

Answer 2

This is a very interesting approach. I would say only two things here:

1. You are really asking for trouble if you use strings and object parameters. Strongly typed EventAggregator events (inheriting from CompositeEvent) are the way to go here. The maintainability will go way up if you do this.
2. Your model for your WCF -> EventAggregator should consider everything to and from the EventAggregator as an "event" and everything to/from the WCF services as "messages". What you should really consider is that you are essentially translating a EventAggregator event to a message, rather than asking the question "how do I raise WCF events".

I think what you are doing is feasible. Looking at your implementation I really like how you are thinking about it.

---

Slight Alternative (w/ strong typing)

I wanted to throw a little something out there and see what you thought about it... maybe it will influence your design slightly. Specifically this is meant to address my first point above and go even further with the strong-typing.

Have you considered having EventAggregator-backed implementations of your service interface? Let's say in your example you have an IWeatherService WCF service that you are working with. Currently, as I understand it, your usage will look something like this:

1. Client uses the WCF Event Client library and calls RaiseEvent("ChangeWeather", Weather.Sunny);
2. The WCF Event Client library translates this into the appropriate call to the WCF service waiting to receive this message, using the IWeatherService channel interface to do so. Probably with a big nasty switch statement based on the name of the method call.

Why not modify this slightly. Make IWeatherService a shared contract among all of the servers and clients. The servers will have the actual implementation, obviously, but the clients will have EventAggregator-backed implementations that go to a central broker that queues and sends messages to servers.

Write an EventAggregator-backed implementation of the IWeatherService that raises events to be received by a central message broker and throw that implementation in your container for clients to use.

public ClientWeatherService : IWeatherService
{

    IEventAggregator _aggregator;
    public ClientWeatherService(IEventAggregator aggregator) 
    { 
     _aggregator = aggregator; 
    }

    public void ChangeWeather(Weather weather)
    {
     ChangeWeatherEvent cwEvent = _aggregator.GetEvent<ChangeWeatherEvent>();
     cwEvent.Publish(weather);
    }
}

From there, instead of using your "WCF Event Client Library" directly, they use the IWeatherService directly, not knowing that it doesn't call the actual service.

public MyWeatherViewModel : ViewModel
{
    IWeatherService _weatherService;
    public MyWeatherViewModel(IWeatherService weatherService)
    {
     _weatherService = weatherService;
    }
}

Then, you'd have some event handler setup to make the WCF calls to the real service, but now you have the benefit of strong-typing from the clients.

Just a thought.

I really like this type of question. I wish more people would ask this kind of thing on Stackoverflow. Gets the brain moving in the morning :)