Reputation: 6506
Since the basic navigation mechanism in Silverlight only allows passing arguments in a querystring, when we want to pass complex data (e.g models) between our views, we use the IEventAggregator's pub\sub mechanism.
But the question is - is there a better way to pass complex information between views?
What are the cons of using the IEventAggregator for this?
Upvotes: 0
Views: 217
Reputation: 8670
This is why I switched to a ViewModel first approach. Views really aren't configurable nor should they really be passing ViewModels around. It made a lot more sense to me for a ViewModel to load another ViewModel like:
Show.Screen<OrderDetailsViewModel>(vm => vm.OrderId = orderId);
This is from the Build your own mvvm framework talk and is also similar to how Caliburn Micro works.
Upvotes: 1
Reputation: 8232
I'm currently using a Session idea, like in ASP.NET. I've defined a static object named SilverlightSession and add a Values property of type Dictionary. Then I just add to the values dictionary or update it and cast it
public static class SilverlightSession
{
public static Dictionary<string, object> Values { get; private set; }
}
in the app.xaml.cs startup:
SilverlightSession.Values = new Dictionary<string, object>();
Then you can have your models in "session" until the application closes.
Upvotes: 0
Reputation: 17905
I can't tell you why IEventAggregator is bad, maybe it's not so intuitive? When you look at your app - you want to see what's going on and doing events with some data doesn't seem to be good. Event is event. You can share some data via Region's context in PRISM.
I'm solving same kind of issues using MEF. So, you can define something like
[Export]
public class MyModelService
{
// Code here whatever shared data you want
}
public class MyViewModel
{
// Import this shared ModelService
[Import]
public MyModelService ModelService
}
So, if you had some data in ModelService - by default MEF will compose it just once (effectively making it shared) and every time you import it inside ViewModel this instance will be there. Then you can use Events originated from ModelService to tell components when data updated, etc.
Upvotes: 0