What is the difference between Sitecore Pipelines and a Sitecore Event Handlers for a specific event? When should we customise a pipeline and when should we add a new handler?
To me pipelines are about process. Do this, then this. Allowing you to insert and remove processes simply with patch configs. A great example of this is
login user pipeline. Your pipeline would be:
- Log user in
- Identify user in xDB
- Add logging info for user
- Add user to marketing automation for returning customer
It is a process flow that you can reorder and add to/subtract from.
Events are one off, very focused actions. Like item:saved vs item:saving. item:renamed vs item:duplicated. They are extremely focused. Although you could tie many events together in the config, they are not very process oriented. It is more about data manipulation than process.
To add to @Chris Auer, think of it this way:
What is the difference
An event is a reaction to something happening in the system. This could be a user interaction, like
item:created, etc, or it could be raised by another process in the system like
publish:end:remote. And there can be many handlers for a single event, just look at some of the
item: events and how many handlers SXA adds to them.
The key point here is that an event reacts to something else being done in the platform.
A pipeline requires something to start that process, but as Chris mentioned, the pipeline is a pattern that starts with some data and then sends that data through various processors to consume, manipulate or add to that data. So you might think of
mvc.getPageItem pipeline; that pipeline takes the initial data about the page context and each processor does something with that data, from setting the language, trying different methods to resolve the page item to hooking into the Content Testing module.
The key for pipelines is that it's processing data.
When should I use event handlers/pipelines
Now we have the distinction, it should be fairly easy to know what you want to use.
If you want to react to an existing event that occurs in the system, you probably want to create an event handler. It is important to remember that hooking into some of the item event handlers can seriously affect your editor performance. You should make sure the code is as performant as you can get it. Don't take shortcuts just because it won't affect the delivery of the site.
As for pipelines, its unusual to create a completely custom pipeline, although it does happen. More often you are hooking into an existing pipeline and adding a processor there. So if you find that you need to change the way something in Sitecore functions, say for example you want to extend the
source property on a
TreeList, then you would be creating a pipeline processor to do that.
I guess the first thing we have to be sure about what we are doing.
Usually, we use events and/or pipelines to decouple process:
In a coupled way of data manipulation/decision, we use mainly 3 different patterns.
1 - Chain of Responsibility: The data flow through every process and one of the process decide if they can handle the process.
2 - Decorator: Every process can change something in the same data.
3 - Composite: Every process add some information to a collection of data, or even to a builder.
The pipeline state a sequence of processes that must be executed in a sequence to produce a result. The sequence of every execution matters.
There are mainly two types of events, the synchronous and the asynchronous.
When a process triggers an asynchronous event it doesn't receive an answer from the triggered event or it can receive a promise that will be fulfilled later.
But events are always very specific to just one thing, while pipelines can have very different steps of implementation.
Using events for querying data is possible. A pipeline is possible too.
To implement a chain of responsability using events or pipeline you have to be able to stop the propagation (avoid that the next process in the pipeline or the next event listener to be executed)
The decorator and the chain of responsability requires a control of se sequence of the processes execution. The pipeline works better here, the event would need a little hack.
But in both cases, you will use a non-canonical implementation. (which is not bad at all)
The pipelines couple the code a litle more than events, because the pipeline must be aware off all the processes that will be executed. In this scenario, the event have a better performance, because the events have no knowledge about how many listeners will be triggered.