El pasado 7 de Mayo tuvo lugar el primer SharePoint Saturday en Madrid en el que tuve la oportunidad de participar como ponente con una charla sobre cómo utilizar Angular 2 dentro de SharePoint/Office.

El evento contó con la presencia de muchos speakers nacionales e internacionales y, entre todos ellos, me sorprendió la sesión que impartió mi compañero Alberto Díaz. En ella habló sobre SharePoint y los diversos frameworks que podemos utilizar: Linq to SharePoint, ENMARCHA, PNP o cualquier otro que conozcáis. En este artículo vamos a ver en qué escenarios podemos plantear usar uno u otro.

Antes de empezar con los Frameworks y sus características, me gustaría dejar claras unas premisas que son obligatorias en SharePoint y en cualquier desarrollo:

• Debemos desarrollar BIEN. ¿Qué entendemos por desarrollar bien? Pues un código que sea legible, que sea fácil de mantener, que se sigan patrones a la hora de programar (y que estos se apliquen bien)… Muchas veces indicamos que tal plataforma no nos permite utilizar una herramienta en cuestión, pero no nos fijamos que lo que hace esa herramienta/utilidad es aplicar un patrón. Nosotros somos profesionales y dentro de nuestros deberes está desarrollar bien y ser independientes de las herramientas (eso es lo que nos diferencia de las máquinas que nosotros pensamos) 😉
• El fin no justifica los medios. Muchas veces por no salir de lo que conocemos (de nuestra zona de confort), evitamos utilizar herramientas/lenguajes en nuestro día a día. Bien porque no sabemos que las podemos utilizar o porque no nos lo hemos planteado. Ahora resulta que las nuevas herramientas para utilizar el nuevo FrameWork sobre SharePoint es Visual Studio Code, Gulp, TypeScript, NodeJS y que debemos de conocerlas sí o sí. Pero, ¿nos hemos planteado que ya las podemos utilizar? Nosotros en ENCAMINA (tengo que decir, y muy orgulloso) hace meses que las estamos utilizando, e incluso en desarrollos en SharePoint 2013.

Linq To SharePoint

LinqToSharePoint salió con la versión de SharePoint 2010 con la intención de suplantar el tedioso infierno que es el lenguaje CamlQuery de una forma muy similar a la que se hace con Entity FrameWork. En un principio esta herramienta tuvo una gran aceptación. Sin embargo, el estancamiento de las mejoras, el que no estuviera directamente integrado con Visual Studio y las limitaciones por temas de rendimiento para consultas cruzadas hizo que su uso fuera decayendo.

Ventajas

• Simplifica el lenguaje de CamlQuery y lo unifica con una de las grandes ventajas que tiene C# y que ha sido copiada por otros lenguajes

Desventajas

• Problemas de rendimiento en algunos casos.
• No se puede utilizar en la versión Online

ENMARCHA

ENMARCHA es una herramienta que hemos desarrollado internamente en ENCAMINA y que esperamos que evolucione con la ayuda y colaboración de la Comunidad junto con todo el equipo de desarrollo de ENCAMINA.

ENMARCHA surge debido a la experiencia que hemos ido adquiriendo en el desarrollo de SharePoint y como hemos solucionado de una forma elegante algunas de las trabas que nos ocurren en SharePoint. Hemos aplicado patrones como el patrón repositorio para el acceso a las listas, de forma que tenemos incorporadas las buenas prácticas de desarrollo en SharePoint sobre el mismo. También hemos podido hacer Unit Testing debido a la incorporación de Interfaces, etc.

Ventajas

• Unifica el acceso a los datos, estableciendo un mapeo entre las clases con las listas de SharePoint
• Posibilidad de hacer Testing
• Desacoplar la lógica de negocio de la vista
• Facilita la integración continua
• Se puede acoplar con otras herramientas como PNP

Desventaja

• Solo es válido para entornos Onpremise (de momento)

Patterns and Practice

El proyecto PNP es un proyecto Open Source liderado por Microsoft junto con muchos miembros de la Comunidad de SharePoint. Es un proyecto que su finalidad es hacer Office 365 y SharePoint mucho mejor y que se estandarice la forma de hacer las cosas.

Ventajas

• Amplia ayuda de la comunidad
• Multitud de proyectos, vídeos y ejemplos de como utilizarlo
• Extensión de las APIS oficiales

Desventajas

• Falta documentación

Resumen

En SharePoint/Office 365 disponemos de muchas opciones y cada una puede ser la más adecuada dependiendo de las necesidades. Pero más allá de los Frameworks, el principal objetivo es hacer buen software y este pasa sí o sí por hacer un buen código. Independiente de la plataforma, nuestra labor es hacer un buen código o por lo menos aplicar todo nuestro conocimiento y buen hacer, para poder hacer el mejor desarrollo posible y como bien dicen en PNP y nuestra RSC:

SHARING IS CARING