Uno de los principales objetivos cuando desarrollamos es hacer un código simple, fácil, eficaz y, si es posible, reutilizarlo. En este post vamos a hablar y ver como hacer un buen código que podamos volver a utilizar.
La API de SharePoint es muy rica y nos permite realizar muchas operaciones, pero hay algunas operaciones que repetimos muy a menudo y lo hacemos utilizando bastante código. Estas operaciones son, por ejemplo, realizar cualquier operación con la Taxonomia, obtener campos de tipo Lookup, Url, Image o Taxonomy, establecer el Tema de un Web, etc. Todas estas operaciones tienen bastante código y, por regla general, las solemos repetir proyecto a proyecto, desarrollo a desarrollo, de forma bastante frecuente.
Una primera aproximación para obtener la solución es realizar todas estas operaciones en una librería independiente y agregarla a nuestra solución de SharePoint. Esta solución está bien, pero existe un gran problema: el equipo de desarrollo que no ha participado en esta creación, no suele utilizarla o no suele conocer toda la funcionalidad existente en esta librería. El motivo de este problema podríamos decir que puede ser la falta de documentación de esta librería, ¡pero no! El problema es que el uso de una de estas librerías no es algo natural. No es lo mismo tener un método como este:
public bool ApplyTheme(SPWeb web, string serverUrl, string composed) { ... }
que uno como este código:
public static bool ApplyTheme (this SPweb, string serverUrl, string composed) { ... }
La diferencia radica en que en el segundo caso hemos utilizado métodos extensores y que los podemos llamar directamente desde cualquier objeto SPWeb. Esto puede hacer que cualquier desarrollo, cuando busque como Aplicar un Tema a un SPWeb y lo vea dentro de la propia definición del propio SPWeb, lo pueda utilizar.
Los métodos de extensión permiten «agregar» métodos a los tipos existentes sin crear un nuevo tipo derivado, recopilar o modificar de otra manera el tipo original. Los métodos de extensión son una clase especial de método estático, pero se les llama como si fueran métodos de instancia en el tipo extendido. No existe ninguna diferencia aparente entre llamar a un método de extensión y llamar a los métodos realmente definidos en un tipo
¡Está claro! El principal beneficio que nos aporta es poder extender la API de SharePoint de forma que incorpore los métodos que más utilizamos en nuestro día a día. De esta forma, enriquecemos nuestro código y reutilizamos nuestro trabajo en el resto de proyecto.
Como he comentado en otras ocasiones, SharePoint no es un producto que NO utilice los mismos patrones y reglas que el resto de desarrollos, tan solo hace falta conocer el producto y los lenguajes que podemos utilizar para exprimirlos y sacarles todo el valor. Hay muchas personas que se creen que SharePoint solo es el sitio donde subir y bajar documentos. Esto hace que no haga falta seguir ninguna pauta a la hora de programar. Este pensamiento lo único que conlleva es muy malos desarrollos y mala reputación al producto. C# es un lenguaje con muchas posibilidades y que, por regla general, no se conocen todas sus virtudes que son muchas.
Este sitio web utiliza cookies para que tengas la mejor experiencia de usuario. Si continuas navegando, estás dando tu consentimiento para aceptar las cookies y también nuestra política de cookies (esperemos que no te empaches con tanta cookie 😊)