--- title: Why Use Prism EventAggregator for .NET App Development? | ArcTouch description: "Our Xamarin app development team explains when and why C# developers should use Prism EventAggregator for .NET app development." url: "https://arctouch.com/blog/prism-eventaggregator-dotnet" date_modified: "2025-10-27T20:44:56.875Z" --- # Why you should use Prism EventAggregator in .NET app development Our Xamarin app development team explains when and why C# developers should use Prism EventAggregator for .NET app development. 5 min. read - April 3, 2020 By Kristof Bergé [](mailto:?subject=Interesting%20blog%20post&body=I%20thought%20you%20might%20like%20this%20blog%20post%20from%20ArcTouch%3A%20https%3A%2F%2Farctouch.com%2Fblog%2Fprism-eventaggregator-dotnet) ![Computer display showing eventaggregator prism dotnet app development](/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2Fefnbmai9c55m%2F3x9twfisWOiheoIFSuNJUl%2F44e889463fe1fa8ac0c834393c05365d%2Feventaggregator-blog-hero-dotnet-app-development&w=3840&q=75) [Prism](https://prismlibrary.com/index.html) is an extensive library for app development in .NET that includes many great features to make your life as a C# developer so much easier. One of these features is the `EventAggregator`. In this post, I’ll explain what the `EventAggregator` is, why it’s so useful, and where you should use it. ## What is Prism EventAggregator? In short, `EventAggregator` is Prism’s implementation of the **Publisher-Subscriber** pattern. Publisher-Subscriber is a messaging pattern designed to facilitate **asynchronous** **communication** in your application. Specifically, it resolves the common problem of sending messages between components that are difficult, impractical, or impossible to link. At its core, the pattern consists of **events** that are **published** to an **event bus**, which in turn passes them to one or more **subscribers**. The subscribers can handle the event in any way they see fit. You can find more detailed information [here](https://docs.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber). _A simple representation of the Publisher-Subscriber pattern_ ## Why use Prism EventAggregator for .NET app development? The Publisher-Subscriber model has various benefits: * **Decoupled**: Publishers and Subscribers don’t know about each other. * **Asynchronous**: The Publisher can quickly send a message and continue with its own work, without having to wait for the Subscriber to finish handling the event. * **Separation of concerns**: Publishers don’t need to know what Subscribers do with the event, and Subscribers don’t need to know where an event comes from. * **Scalable**: No matter how many publishers, subscribers, and events you have, you only ever need a reference to one event bus. `EventAggregator` has all these benefits and adds a few more that are especially helpful in .NET app development: * **Prevent memory leaks**: `EventAggregator` will NOT keep a reference of any subscribers that were disposed. There’s no reason to unsubscribe manually. * **Send complex objects**: Send complex objects as a parameter when publishing an event to give the subscriber more context and info when handling the event. * **Thread flexibility**: Choose which thread to handle incoming events. * **Filter events**: Subscribers can choose which events to process and which to ignore. ## When to use Prism EventAggregator? To recap, Publisher-Subscriber is a messaging pattern designed for communication between components that are difficult or impractical to link. In a Prism project, `EventAggregator` is often used to send messages between two or more ViewModels, or between services that don’t have a reference to each other. Another use case is when one event needs to be handled by many different subscribers, and it wouldn’t be practical to pass a publisher reference to each of these subscribers. ## EventAggregator in Xamarin.Forms If you’re familiar with Xamarin.Forms, you may be thinking, “Wait, doesn’t Xamarin.Forms already have something like this?” And you’d be right — Xamarin.Forms has its own implementation of Publisher-Subscriber, namely **MessagingCenter**. But I prefer Prism’s `EventAggregator` for these reasons: * **Memory leaks**: MessagingCenter will keep a reference to any disposed subscribers if you don’t unsubscribe manually. (Just Google “[Xamarin MessagingCenter memory leaks](https://www.google.com/search?q=xamarin+messagingcenter+memory+leaks)” and you’ll find many forum posts about performance issues.) * **Flexibility**: MessagingCenter doesn’t have thread flexibility or event filters like `EventAggregator` does. * **Testability**: MessagingCenter uses static methods, which makes writing unit tests more difficult. Prism, on the other hand, will automatically inject an `EventAggregator` instance into the constructor, so you can mock it easily. ## A few words of warning I hope by now you’re convinced of the flexibility and utility of `EventAggregator`, but as always, there are some things to watch out for. Although `EventAggregator` holds only weak references to subscribers, it’s still possible that it will hold a strong reference IF the publisher **passes a parameter** AND the subscriber **holds a reference** to that parameter. So if you need to do this, it’s a good idea to unsubscribe manually when your subscriber is disposed. Also, while the decoupled structure of `EventAggregator` is great, it can lead to increased complexity when overused. There may be a separation of concerns between publisher and subscriber, but there isn’t between the events themselves (they’re all kept in the same `EventAggregator`). In large projects with many events, this may obscure communication flows. My advice is to only use `EventAggregator` where it’s necessary. Don’t structure your whole project around it. Like with everything in life, moderation is key. ## Follow us to learn more about Prism EventAggregator There are many reasons to use `EventAggregator` in your Prism project and for .NET app development. In an upcoming post, we’ll explain HOW to use it with code samples. So make sure to follow us on [Facebook](https://www.facebook.com/arctouch/), [Twitter](https://twitter.com/ArcTouch), and [LinkedIn](https://www.linkedin.com/company/arctouch/) to be notified about it. ## Article Author: [KB | Kristof Bergé | ArcTouch employee](/blog/author/kristof-berge) ## Tags: [Agile Development](/tag/agile-development) [Best Practices](/tag/best-practices) [Developer Tips](/tag/developer-tips) [Enterprise Applications](/tag/enterprise-applications) [Xamarin](/tag/xamarin) ## Subscribe for more insights Get our newsletter in your inbox. ## Related posts [12 web accessibility best practices: A starter list | ArcTouch shares 12 best practices that provide a great starting point for building accessible web experiences. | 5 min. read - April 16, 2024](/blog/web-accessibility-best-practices) [Injecting AI into software development — an ArcTouch blog series | The ArcTouch design and development team shares how to use AI to build lovable apps and websites — better and faster. | 5 min. read - April 9, 2024](/blog/ai-software-development) ## Contact us. ### Let's build something lovable. Together. We help companies of all sizes build lovable apps, websites, and connected experiences.