Event Receivers in SharePoint 2010-What, Why and How

What
Say you’ve got a SharePoint site up and running and you need to provide a hook for some custom programming logic that only occurs when certain events are triggered from SharePoint. Some examples of the most basic events would be when a user on the site adds, updates, or deletes an SPListItem (either through the OOB GUI or some custom implementation). Thinking about events in SharePoint is akin to thinking about events in C# (Click, Hover, ItemDataBound, etc…) for example. A user performs an action, and some block of code executes when thatsomething is done (or possibly before that something is done).

Why
As was alluded to above, often times there are needs to run a block of code after (or during) an event in SharePoint. Such examples could be cleanup jobs, or potentially database-level data synchronization needs, it all boils down to the project needs.  Bottom line is most projects are predominately event-driven, so event receivers are a core part of your toolkit when integrating SharePoint into a project solution.

How
I’ll start with a birds-eye view before diving into some detailed code examples. If you want SharePoint to leverage Event Receivers, one way to do so is by authoring your own custom assembly that you strong-name and GAC. Afterwards, all that is necessary is to subscribe (a.k.a.  register if you prefer) SharePoint to the specific events within the GAC’d assembly (more on that in a moment).

If you need some action to occur when a user deletes a document, for example, you may right away think you need a workflow when in fact an event receiver will do. The main difference between the two is a workflow is typically long running, whereas an event receiver is immediate.

Why would you want an event receiver? What if all you wanted to do is execute a piece of code when a document is being deleted. Say you wanted with code to archive that document when a user goes to delete it. This is a great example where an event receiver is nice, because that deleting event can trigger your custom code. You could do this with a Visual Studio workflow that just has one activity in it, but that's a lot of overhead for something that an event receiver does with a lot less effort. Alternatively, you could use a SharePoint Designer workflow, but with SPD you can't move documents across the site collection boundary, so custom code is the only way to go. The table below shows more comparisons between workflows and event receivers:

Comparing a workflow with an event receivers

Event Receivers		Workflows
Immediate fire	Versus	"Long running"
Lives and dies (no state)	Versus	Maintains "state"
.NET code only	Versus	.NET or SharePoint Designer
No human interaction	Versus	Typically involves human interaction
Before or after events	Versus	Only After events
Executes on sites, features, lists, and list items	Versus	Executes on Sites, items, and content types.

You really can't say one is better than the other. It depends entirely on your business requirements. Besides when documents are deleted, there are many other events you can respond to. The events fall into six categories as shown in the table below. Each category has a few of the more common events shown in the second column, but note there are many more events available as well.

Six event receiver categories

List Events	Adding/ed a new list, field. Updating/ed a field.
List Item Events	Adding/ed a new list item or document. Document checking/ed in or out. Adding/ed an attachment. Deleting/ed an item or document.
List Email Events	A list received an email.
Web Events	Deleting/ed a site collection or site. Creating/ed a new site collection or sub site.
Feature Events	Feature activating/ed or deactivating/ed.
List Workflow Events	A workflow is starting/ed, postponed, or completed.

You'll notice two things in this table. First is that there are a ton of events that you can have custom code respond to, and secondly that most events have a "before" and "after" (adding/added) event associated with it. As shown in Figure 1, before events happened before the change is committed to the SharePoint content database. This is helpful when you may want to cancel a change before it is saved. The event receiver for when a site is being deleted is a good example. Before the site is deleted, you could back it up first. On the other hand, there's a corresponding event receiver for after the site was deleted.

Figure 1 Events typically have a "before" and an "after" event, corresponding to when the event happens in relation to when the source is committed to the database.