Solved

Are both the EventAggregator used by ViewModel and Domain Event used by Model the same thing?

Posted on 2013-01-05
4
778 Views
Last Modified: 2013-01-15
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?
0
Comment
Question by:xenonn
  • 2
4 Comments
 
LVL 19

Expert Comment

by:Manoj Patil
ID: 38749175
0
 
LVL 37

Expert Comment

by:TommySzalapski
ID: 38758920
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.
0
 

Author Comment

by:xenonn
ID: 38759075
@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.
0
 
LVL 37

Accepted Solution

by:
TommySzalapski earned 500 total points
ID: 38759109
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?
Precisely.

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
No. The ViewModel talks directly to the Model. The Domain Event Aggregator is for the Models to talk to each other. I would actually avoid the Event Aggregator as often as possible. I don't like the idea of ViewModels talking to each other. The Models should do most of the talking.

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?
Well, if you inherit both from a common aggregator base class, then you can do all of the shared implementation there and avoid the redundancy.
0

Featured Post

Courses: Start Training Online With Pros, Today

Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Since upgrading to Office 2013 or higher installing the Smart Indenter addin will fail. This article will explain how to install it so it will work regardless of the Office version installed.
Whether you’re a college noob or a soon-to-be pro, these tips are sure to help you in your journey to becoming a programming ninja and stand out from the crowd.
With the power of JIRA, there's an unlimited number of ways you can customize it, use it and benefit from it. With that in mind, there's bound to be things that I wasn't able to cover in this course. With this summary we'll look at some places to go…
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

786 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question