[SharePoint 2013] Como optimizar el acceso a los datos en listas

Para todo desarrollador/analista/arquitecto que NO haya visto SharePoint en la vida cuando se planta ante la idea de querer optimizar el acceso a los datos la primera idea que le viene es la introducir un modulo de persistencia de datos. Y cuando les comentas que eso en SharePoint no es recomendable lo lógico es que te digan que es una muy mala practica no hacerlo. El no hacerlo era una practica que se hacia hace mucho tiempo (antes que existieran los lenguajes orientados a objetos aprox.), en que no se seguían ningún patrón y su única función era hacer que las cosas funcionaran. Los desarrolladores llamábamos desde nuestra aplicación de escritorio directamente las consultas SQL o de ficheros físicos para acceder a los datos, con el retardo que ello llevaba y la poca reutilización que se hacia y en el momento que se producía un cambio en alguna tabla de la Base de Datos ya se había provocado un incendio. Posteriormente ya se introdujo Linq y un paso mas los módulos de persistencia de datos como NHibernate.

Cuando comento que NO es recomendable estos módulos de persistencias hay que desarrollar un poco más esta respuesta. En primer lugar las listas en SharePoint no son los mismos que la tablas de cualquier Base de Datos, las listas para que fueran igual que las tablas en primer lugar tendrían que ser relacionales y no lo son. Esta es la principal base por la que pienso que no hace falta un modulo de persistencia de datos, estos módulos se basan en la relacionalidad de las tablas por lo que hacer esto en base a lista carece de sentido. SharePoint no es relacional y no es su función, no viene a sustituir al ERP o quiere que tengamos millones de registros almacenos sino a complementar aspectos de las organizaciones para mejorarlas y hacerlas más productivas.
Ahora bien que no tengamos un modulo de persistencia de datos no quiere decir que tengamos que hacer las cosas mal y hacer las cosas como hace veinte años. Por lo general las páginas de SharePoint suelen ser bastante pesadas por lo que si queremos tener una aplicación web que los usuarios no se duerman entre click y click tenemos que saber bien como realizamos las llamadas, el optimizar estas consultas y el ver los puntos débiles que tiene nuestra aplicación y esto SI que es necesario que lo tengamos controlado y sepamos como mirarlo. Para empezar también tenemos una herramienta como LINQ To SharePoint que parece optima utilizar para esto no?, pero sin embargo es algo que yo personalmente no utilizo. El motivo, principalmente por rendimiento cuando estamos utilizando LINQ to SharePoint lo que esta haciendo internamente es montar la sentencia CAML Query corresponiente, por lo que en primer lugar montamos el LINQ y posteriormente genera la Consulta para obtener los datos por lo que estamos perdiendo rendimiento en nuestra aplicación.
Entonces solo nos quedaría la solución de hacer las CAML Query directamente no? Si pero no, la opción que empleamos para el tratamiento de datos en SharePoint es la de crear de forma manual un repositorio de datos. Antes de crear este repositorio lo que hacemos es transformar las listas de SharePoint en Objetos .Net de toda la vida. El motivo del cual devolver en objetos es que una vez tenemos el objeto ya podemos aplicar LINQ para empezar a filtrar los datos que obtenemos o realizar alguna opción aritmética. Ahora bien una vez tenemos los elementos creados el siguiente paso es ya crearnos el repositorio de estos objetos en los que tendremos las operaciones más comunes que vamos a realizas, por ejemplo si estamos en caso de consultar una lista de empleados pues en este repositorio, tendremos un procedimiento que nos devuelve todos los empleados de un determinado departamento, todos los empleados de la empresa, o dado un empleado devolvernos un departamento. La idea de hacer todo esto para que podamos reutilizar código consultas, y no tengamos la misma consulta escrita en 80 lugares de la aplicación y si por alguna de aquella queremos mejorar su rendimiento pues no te quiero contar la faena que tiene. De esta forma vamos fraccionando la aplicación en diversos módulos y así cualquier modificación en una parte no tiene consecuencias en el resto de módulos.
La estructura de la aplicación quedaría de la siguiente forma (algo similar a lo que plantee en el WebCast de SUGES:

Una vez tenemos aplicada las buenas practicas queda el saber optimizar las consultas que se realizan al Objeto SPQuery, el primer fallo que se emplea es que solo añadimos la opción de filtro y con eso quizás estamos consiguiendo filtrar los resultados que queremos pero nos estamos trayendo todos los campos que tiene esa lista aunque NO todos nos hacen falta. Para ello con rellenar los campos que nos vamos a traer en la propiedad ViewList seria suficiente:

SPQuery query = New SPQuery();
query.ViewFields = ;
query.ViewFieldsOnly = true;

El siguiente error que cometemos para el acceso a datos es que hacemos una consulta CAML Query y nunca limitamos el número de elementos, en mi opinión aunque pensemos que nunca vamos a llegar a tener un máximo número de registros hay que ponerlo porque si por alguna de aquellas el número de registros que esperamos es superior a lo esperado la aplicación lo va a notar. Por ejemplo tenemos una lista de los empleados de una empresa pero la empresa empieza a crecer (buen signo) y donde antes habían 200 empleados ahora hay 2000 por lo que las consultas no tardan lo mismo. Llegado a ese punto conviene entrar en buscar otras medidas bien paginar, bien pedir de bloques en bloques, utilizando caches de datos, … y esto se obtiene limitando el número de elementos que hay en una consulta para ello nos valdría el siguiente ejemplo:

query.RowLimit= 50;

Y una vez realizado esto también tendremos que pensar en el sentido común y es aplicar otras técnicas auxiliares, es decir si mi aplicación va a consultar muchas veces una consulta quizás lo mejor es que tengamos esta consulta en Cache durante un tiempo determinado y de esta forma le daremos mucha más velocidad a la aplicación. Por ejemplo tenemos en una lista el número de empleados y este número de empleados se consulta permanentemente pues una opción de que este elemento lo tengamos en cache bien podemos utilizar el ViewState(opción que a mi me gusta menos porque carga mas el servidor) o bien HttpRuntime.Cache (que lo almacena en la cache del cliente).
Y como medida adicional a todo esto no esta de más monitorizar el acceso al SQL donde esta almacenado la base de datos de contenido y observemos el número de accesos que se producen y ver las consultas que se realizan y si alguna de estas consultas se puede mejorar pues adelante.

Aunque todo esto parezcan pequeñas cosas y que no tienen importancia, si empezamos a sumar y vemos que la carga de nuestra aplicación antes tardaba 15 segundos  ahora en 2 segundo esta cargada pues es un gran paso. Lo primero hace que el cliente este satisfecho con el producto que se le ha desarrollado y lo segundo es que a nosotros como desarrolladores estamos satisfechos porque no solo hemos realizado una aplicación, sino que ademas hemos introducido nuestros conocimientos para dar la mejor solución posible en términos de calidad del software y eso al menos para mi es muy importante.