Work towards #56: Splitting up the README
I did the job and splitted up the readme, hopefully everything was splitted correctly...
This commit is contained in:
24
event-aggregator/index.md
Normal file
24
event-aggregator/index.md
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
layout: pattern
|
||||
title: Event Aggregator
|
||||
folder: event-aggregator
|
||||
categories: pattern_cat
|
||||
tags: pattern_tag
|
||||
---
|
||||
|
||||
**Intent:** A system with lots of objects can lead to complexities when a
|
||||
client wants to subscribe to events. The client has to find and register for
|
||||
each object individually, if each object has multiple events then each event
|
||||
requires a separate subscription. An Event Aggregator acts as a single source
|
||||
of events for many objects. It registers for all the events of the many objects
|
||||
allowing clients to register with just the aggregator.
|
||||
|
||||

|
||||
|
||||
**Applicability:** Use the Event Aggregator pattern when
|
||||
|
||||
* Event Aggregator is a good choice when you have lots of objects that are
|
||||
potential event sources. Rather than have the observer deal with registering
|
||||
with them all, you can centralize the registration logic to the Event
|
||||
Aggregator. As well as simplifying registration, a Event Aggregator also
|
||||
simplifies the memory management issues in using observers.
|
Reference in New Issue
Block a user