Asignar un EventReceiver a una única lista de SharePoint

Una de las críticas que se le achaca a Visual Studio es que nos hace pensar poco a los desarrolladores y muchas veces nos acostumbramos a la plantilla/Wizard común sin meditar si es la mejor opción o la solución que queremos hacer.

En este post, vamos a ver cómo podemos asignar un EventReceiver a una única lista de SharePoint y vamos a corregir el mal uso que se hace del Wizard del EventReceiver. Muchas personas atribuyen la culpa al Visual Studio y, por una parte, estamos de acuerdo. El Visual Studio hace que los programadores no piensen y den por buena la generación del Wizard. Sin embargo, lo cierto es que el máximo culpable es el desarrollador por utilizar la herramienta de forma incorrecta y no solucionar su uso indebido.

¿Qué es un EventReceiver?
Un EventReceiver, como bien indica su traducción del inglés, es un receptor de eventos. Estos eventos acontecen en SharePoint, desde que se crea un sitio, hasta que se elimina un elemento. Todo lo que ocurre dentro de nuestro sitio tiene un evento asignado y se puede extender su funcionalidad.
Se suelen confundir los términos EventRecevier, Workflow o TimerJob. Aunque no es el objeto de este post analizar cuándo utilizar uno u otro, queremos explicara los diferentes usos de cada uno. A grandes rasgos, utilizamos TimerJob cuando queremos realizar alguna acción de forma periódica y un Workflow cuando queremos indicar un proceso más complejo, como por ejemplo una acción que dependa de la aprobación de varias personas. Por último, utilizamos EventReceiver cuando queremos realizar una acción (es decir, producir un evento) que no depende de tiempo ni de elementos externos. Por ejemplo, queremos enviar una notificación en tiempo real (ya sea vía web o móvil) cuando se inserta un elemento en una lista.

Cómo funciona el Wizard del EventReceiver. 
1.- Creamos un proyecto vacío de SharePoint.
2.- Añadimos el EventoReceiver, seleccionamos la template para ello.
3.- A continuación, se muestra la siguiente pantalla

En el primer campo, seleccionamos el tipo de artefacto del evento que queremos implementar (List Events, List Items Events, Web Events o List Workflows).
A continuación, se seleccionan las plantillas de estos elementos. Ejemplo: Bibliotecas de Documentos, bibliotecas personalizadas, etc…
Finalmente, escogemos el evento que queremos desarrollar (bien cuando se este creando un elemento, cuando se haya añadido, etc).

Si vemos lo que ha generado este Wizard, por un lado tenemos el EventReceiver y, por otro lado, una Feature hace que este EventReceiver se instale en todos los elementos indicados, tal y como se muestra en esta imagen:

Hasta aquí todo parece más o menos claro, entonces… ¿qué es lo está mal realmente? Además, nuestro objetivo es que el EventReceiver se ejecute sobre la una determinada lista, por ejemplo, una lista  de Proyectos. ¿Este Wizard lo hace? ¿Dónde lo configuramos?

En este pensamiento es dónde reside el daño del Wizard de los EventReceiver y la mala práctica de algunos desarrolladores:

«Como tengo el EventReceiver implementado, con solamente añadir una condición en el código, lo tengo solucionado»

Vale, puede que ésta sea una solución pero no la correcta. NO debemos de aceptarla porque es una muy mala práctica y puede provocar gran cantidad de daños colaterales (que el programador ni siquiera ha pensado). Aquí lanzamos un recordatorio: por defecto, el Wizard de los EventReceiver añade esta acción a todos los elementos del sitio. Esto hace que (posteriormente) podamos tener problemas de rendimiento. No es una buena opción tener un EventReceiver en todas las listas de nuestro sitio para solamente, en el caso de que sea la que nos interese, realizar una acción.

Cómo solucionarlo

Para solucionar este «inconveniente», en primer lugar quitamos este EventReceiver del despliegue de la Feature, para que cuando la activemos no lo asociemos a todos estos elementos de ese ámbito.

El siguiente paso es añadir el code-behind en esa Feature y  (dentro del artefacto que deseamos, como por ejemplo, una lista), asociarle el EventReceiver que hemos implementado anteriormente. Para ello, dentro del Server Object Model de SharePoint (SSOM) a un objeto de tipo SPList, podemos añadirle un evento que esté dentro de nuestro ensamblado como el siguiente código

    public static void AddEventReceiverToList(SPWeb web, string listName, SPEventReceiverType eventType, string namespaceMethod)
       {
            try
            {
                var list = web.Lists.TryGetList(listName);
                if (list != null)
                {
                    list.EventReceivers.Add(eventType, Assembly.GetExecutingAssembly().FullName, namespaceMethod);
                }
            }
            catch (Exception exception)
            {
                Logger.Error(string.Concat("Error AddEventReceiver",exception.Message));
            }
       }

Conclusión

Usar los asistentes está muy bien cuando empezamos a utilizar algo que no sabemos como funciona, algo que desconocemos. De esta forma, nos familiarizamos con los métodos, practicamos y asentamos conceptos hasta que cogemos algo de destreza. Pero, una vez aprendida la funcionalidad, el uso de los asistentes nos causa más problemas que beneficios, como ha quedado claro en el ejemplo descrito. Tal y como decíamos al inicio del post, la culpa no es de Visual Studio. La responsabilidad final recae en el desarrollador que es el último responsable del código que genera, las librerías que utiliza y, sobre todo, de cómo lo utiliza.