SharePoint List Access Layer Generator
En implémentant des solutions SharePoint, on est toujours amené à manipuler des éléments dans des listes en mode CRUD.
Le code ci-dessous présente une manière classique de manipulation de Liste :
using (SPSite Site = new SPSite("Url"))
{
using (SPWeb Web = Site.OpenWeb())
{
SPList oList = Web.Lists["MyCustomList"];
SPListItem oListItem = oList.Items.GetItemById(1);
oListItem["MonChamp"] = "NouvelleValeur";
}
}
ou bien
using (SPSite Site = new SPSite("Url"))
{
using (SPWeb Web = Site.OpenWeb())
{
SPList oList = Web.Lists["MyCustomList"];
SPListItem oListItem = oList.Items.GetItemById(1);
oListItem["D91D43BC-179A-44ec-AEE6-E23650EE0"] = "NewValeur";
}
}
La première écriture présente des inconvénients dans le sens ou le développeur doit toujours revenir au site SharePoint pour s’assurer de la bonne écriture du nom du champ.
La deuxième écriture ne donne aucune signification sur le nom du champ à modifier.
La solution propsée au niveau de ce post se repose sur un outil développé au niveau du CodePlex SharePoint List Access Generator (http://splalgenerator.codeplex.com/)
Splalgenerator génére des classes d’accés aux listes pour la manipulation des éléments des Listes. Les classes sont configurées par les paramètres de site c’est-à-dire Url, GuidList et Guid des champs.
Le code ci-dessus devient :
MyCustomList myCustomList = new MyCustomList(1) ;
myCustomList.MonChamp = "NouvelleValeur" ;
Cette manière d’écriture est plus élégante. En plus, elle fait gagner beaucoup du temps lors du développement, car j’ai vu beaucoup de développeurs construisant leurs propres classes de manipulation de List en configurant leurs listes par les guid des éléments. Mais cette solution est couteuse en termes de temps de développement car le développeur est censé maintenir ses classes à jour.
Pour que notre solution demeure valable même en environnement de déploiement chez le client, il est important de créer nos propres content types.
Aucun commentaire:
Enregistrer un commentaire