Shared data across modules

Topics: Prism v4 - WPF 4
May 6, 2014 at 11:31 PM
Hello,

My current solution consists of ModuleA with ModelA (ID, Name) and ModuleB. I initialize ModuleB through a command from ModuleA and passing ID and Name as string parameters in the UriQuery. I know that is not possible to pass the whole object ModelA as a parameter. Is there another way?

Thanks
May 7, 2014 at 4:08 PM
Hello,

In order to pass the entire object through Modules, you could use the EventAggregator approach by working on Prism 4.1. As you may see on the EventAggregation QuickStart, this feature would let you communicate between Modules and pass also an object as parameter.

Therefore, for implementing this you may need to first initialize ModuleB in the ModuleA's CommandHandler, so that ModuleB suscribes to the Event that ModuleA would Publish afterwards. And then, ModuleA would Publish the Event from the CommandHandler, passing the ModelA object as parameter to the ViewModel that would handle the event suscription.

Anyway, I would like to point out that new versions of Prism 4.2 and 5 has been released and they resolve the object parameters passing through UriQuery. You may find more information in the Prism 5 MSDN Guide:

I hope this helped you,
Regards.

Gabriel Ostrowsky
https://blogs.southworks.net/gostrowsky
May 8, 2014 at 10:44 AM
Hello,

Thank you very much for your reply.

If I use the EventAggregator approach, how can ModuleB know the type of ModelA, so that it can unbox it and access its properties?

I tried to find and download Prism 4.2 but with no luck. Since I am currently using Template Pack from David Hill, will I be able to use Prism 5.0 with no problems?

Thanks,
May 8, 2014 at 3:46 PM
Hi,

I am afraid I am not able to download the Prism template Pack as the Download site does not get resolved. However, at a first glance I would say that you could use the template, and then change the reference assemblies to Prism 5. In addition, I don't know what .NET version would the template be using, so you may need to update it to 4.5.

Nevertheless, the EventAggregator works with declared Events which would define a specific parameter type. Therefore, when ModuleB suscribes to that particular Event, it would actually know that the event's parameter type would be the one corresponding to the particular Event definition.
As you may see in the EventAggregation Quickstart, the FundAddedEvent class defined in the Infrastructure project, is declaring the Event with the generics parameter type that it would use. So when ModuleA would Publish the particular Event, it would need to necessarily pass the expected argument as well as the Suscriber would need to receive the argument on the EventHandler method:
public class FundAddedEvent : CompositePresentationEvent<FundOrder>
{
}

ModuleA - AddFundPresenter.cs (Publisher):
...
eventAggregator.GetEvent<FundAddedEvent>().Publish(fundOrder);

ModuleB - ActivityPresenter.cs (Suscriber):
...
public void FundAddedEventHandler(FundOrder fundOrder){
...
If you don't want to reference ModuleA from ModuleB, you could create a common class on the Infrastructure project for example in order to be configured with ModelA important information, and be used as the Event argument.

I hope this helped you,
Regards.

Gabriel Ostrowsky.
https://blogs.southworks.net/gostrowsky
Marked as answer by abampakos on 5/11/2014 at 3:54 AM