Solved

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

Posted on 2013-01-05
4
763 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
Comment Utility
0
 
LVL 37

Expert Comment

by:TommySzalapski
Comment Utility
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
Comment Utility
@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
Comment Utility
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

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Entering a date in Microsoft Access can be tricky. A typo can cause month and day to be shuffled, entering the day only causes an error, as does entering, say, day 31 in June. This article shows how an inputmask supported by code can help the user a…
Calculating holidays and working days is a function that is often needed yet it is not one found within the Framework. This article presents one approach to building a working-day calculator for use in .NET.
In this fourth video of the Xpdf series, we discuss and demonstrate the PDFinfo utility, which retrieves the contents of a PDF's Info Dictionary, as well as some other information, including the page count. We show how to isolate the page count in a…
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…

771 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now