Sharepoint - When to use Server side event receivers Versus using Remote event receivers?
Answering your 4 questions:
Differences
- Remote Event Receiver (RER) -
A provider hosted app is must, which means you need additional infra. Apparently, as pointed out by Mihail-Florin Popa, it is no longer true.- Works using web services, you expose web services on your provider hosted app, that are called when an event is fired.
- Only Client Object Model is available inside the event receiver code, so you'll be limited by CSOM's limitations.
- This is the only option to override events if you have O365/SharePoint online.
- Using this approach makes your code future safe, when SOM is killed finally.
- This is the list of events available to override.
- SharePoint Event Receivers (SER)
- No additional infra required to host event receiver code.
- Works using code running in context of W3WP.exe in case of farm solutions and spucworkerprocess.exe in case of SandBox solutions.
- Full fledged SOM API is available in case of farm solutions, no limits.
- This is only available in On-Premises environment.
- This might be deprecated or unsupported in future releases.
- This is the list of events available to override in SER.
- Remote Event Receiver (RER) -
You have a choice only in case of On-Premises otherwise you HAVE to use RERS. However, to be future safe, you should start using RERs if it fulfills all your requirements as the App Model is the future of SharePoint.
Both will fulfill your requirements reliably and efficiently, the decision depends upon your decision about future readiness and investment in hosting another application.
This can be achieved by List Validation formula without using event receivers at all, in fact event receivers would be an unnecessary overhead. That would be the recommended approach to do it. You can refer this article to learn about it.
At first,
Remote event receivers are mainly introduced for cloud or office 365 environment (SharePoint Online) where the core logic will run in an hosted environment outside of SharePoint Sites and still try to achieve the regular event handler functionalities.
You can still develop them for as SharePoint Ad-In's even in 2013 server but i will list out couple of major differences here:
Remote event recieverers have lot of complexity because you need to setup the app domain, app-catalog, trust and so on as they can be hosted in cloud or another iis server.
Core logic will run outside of the SharePoint site calling a custom or out of the box web service, trigger workflows to handle the actual events.
Now coming to your two requirements, ITEM Added and Adding events in the regular SharePoint Farm solution are best suitable for you to add or append the html and also it (Item Adding event) can stop/prevent the event firing during the course based on the conditions of the field values.
if you want a future proof solution, then you should consider using remote event receiver else you can opt for the standard Farm solution based event receivers as you can achieve this functionality with both.
- In Remote event receiver custom logic is executed outside of Sharepoint runtime
- If you are sure you move in the future to the cloud use the remote, otherwise use server side.
Answer depends on question, will you move to cloud (o365) because server side event are not supported in the cloud.
you need to wire your event to item updated to stop the update from saving.