xenonn
asked on
Are both the EventAggregator used by ViewModel and Domain Event used by Model the same thing?
My initial doubt was should the Model classes in an MVVM use the EventAggregator or the traditional delegates in C# for events. I searched around and read about the Domain Events. It seems to me that for the Model classes, they should use the Domain Events instead of the EventAggregator, which is for the UI.
So, it would work out as something like: The ViewModels would use the EventAggregator to dispatch events between the other ViewModels. The Model classes would dispatch events on the Domain Event aggregator. The ViewModels, which knows about its own specific Model, will listen to the Model's Domain Events. The Models would communicate with the other Models through the Domain Events, decoupling among themselves. This would entirely eradicate the use of the traditional C# events.
Up till this point, I hope I'm understanding all that I've read correctly.
Now, here's what I don't understand. Both the Domain Event and EventAggregator look the same to me, at least for the Domain Event aggregator posted on Udi Dahan's blog. So does it mean that within the application, I will use two EventAggregators, one for the ViewModels and one for the Models. The one used by the ViewModel is still called the EventAggregator, whereas the one used by the Models is called Domain Event.
Does this imply that both the Domain Event used by the Models and the EventAggregator used by the ViewModels are both of the same implementation of EventAggregator, except that they are created as two different instances within the application, ie, two of the same kind of EventAggregators within the application but only used for different purposes? If this is true, since it's the same implementation, why not just use one common EventAggregator for both the ViewModels and Models?
So, it would work out as something like: The ViewModels would use the EventAggregator to dispatch events between the other ViewModels. The Model classes would dispatch events on the Domain Event aggregator. The ViewModels, which knows about its own specific Model, will listen to the Model's Domain Events. The Models would communicate with the other Models through the Domain Events, decoupling among themselves. This would entirely eradicate the use of the traditional C# events.
Up till this point, I hope I'm understanding all that I've read correctly.
Now, here's what I don't understand. Both the Domain Event and EventAggregator look the same to me, at least for the Domain Event aggregator posted on Udi Dahan's blog. So does it mean that within the application, I will use two EventAggregators, one for the ViewModels and one for the Models. The one used by the ViewModel is still called the EventAggregator, whereas the one used by the Models is called Domain Event.
Does this imply that both the Domain Event used by the Models and the EventAggregator used by the ViewModels are both of the same implementation of EventAggregator, except that they are created as two different instances within the application, ie, two of the same kind of EventAggregators within the application but only used for different purposes? If this is true, since it's the same implementation, why not just use one common EventAggregator for both the ViewModels and Models?
Notice that even you have referred to it as a "Domain Event Aggregator." As you have guessed, and as the name suggests, the Domain Event Aggregator is just an Event Aggregator that works on the domain level (Models).
The reason you don't just use the same class for the ViewModels' event aggregator and the Models' event aggregator is that they operate differently. They talk to different classes so they need to be able to communicate in a different way.
It is entirely possible that they could share a base class, but some of the implementation should be different.
The reason you don't just use the same class for the ViewModels' event aggregator and the Models' event aggregator is that they operate differently. They talk to different classes so they need to be able to communicate in a different way.
It is entirely possible that they could share a base class, but some of the implementation should be different.
ASKER
@TommySzalapski, thanks for your answer!
Just to clarify a little more though, in terms of implementation, how do the Domain Event Aggregator and the ViewModel's Event Aggregator differ in terms of implementation?
Does this mean that the Domain Event Aggregator is used solely between the Models and the normal Event Aggregator is used solely between the ViewModels?
Also, I could imagine how this could cause extra code or repeating code because of this rule. The ViewModels suppose to know about their Models, and the ViewModels need to communicate with the Models. If the Models are using the Domain Event Aggregator to dispatch events, then the ViewModel will need dependencies of both the normal Event Aggregator (for communication between the ViewModels) and the Domain Event Aggregator (for communicate between its own Model). The whole communication becomes more complicated (and verbose) because the ViewModel will end up listening to the Domain Event Aggregator, and then propagate the same event from the Domain EventAggregator through the ViewModels' normal Event Aggregator. Why not just use one Event Aggregator? It seems to me that I'm missing out something which could have helped me to appreciate the use of having 2 separate event aggregators.
Just to clarify a little more though, in terms of implementation, how do the Domain Event Aggregator and the ViewModel's Event Aggregator differ in terms of implementation?
Does this mean that the Domain Event Aggregator is used solely between the Models and the normal Event Aggregator is used solely between the ViewModels?
Also, I could imagine how this could cause extra code or repeating code because of this rule. The ViewModels suppose to know about their Models, and the ViewModels need to communicate with the Models. If the Models are using the Domain Event Aggregator to dispatch events, then the ViewModel will need dependencies of both the normal Event Aggregator (for communication between the ViewModels) and the Domain Event Aggregator (for communicate between its own Model). The whole communication becomes more complicated (and verbose) because the ViewModel will end up listening to the Domain Event Aggregator, and then propagate the same event from the Domain EventAggregator through the ViewModels' normal Event Aggregator. Why not just use one Event Aggregator? It seems to me that I'm missing out something which could have helped me to appreciate the use of having 2 separate event aggregators.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
http://www.codeproject.com/Articles/221585/Step-By-Step-Guide-To-MVVM
http://msdn.microsoft.com/en-us/library/gg430857(v=pandp.40).aspx
http://ordonnancement.org/wpf-silverlight-step-by-step-guide-to-mvvm/the-code-project---a-new-task-scheduler-class-library-for-.net---c-programming/news1084572.html