Life in DotNet

Introduzione alle Client-Side API di SharePoint 2010

Salve,

con sharepoint 2010 adesso sono previste delle librerie lato client per poter comunicare col server, di seguito vi riporto il testo di un articolo scritto da Giuseppe Marchi sul sito sharepointcommunity.it:

La nuova versione di SharePoint vede la presenza di nuove librerie contenti un particolare modello ad oggetti utile a permettere a tutte quelle applicazioni che vengono eseguite lato client, quindi che non girano nel contesto server di SharePoint stesso (come window form, applicazioni console, servizi windows, applicazioni Silverlight, ecc..), di effettuare operazioni su siti, liste, documenti, elementi e tutte le altre tipologie di oggetti senza richiamare i web service esposti, come siamo sempre stati abituati fin’ora e, soprattutto, potendo mantenere un paradigma ad oggetti.
Per coprire l’intero insieme di applicazioni che solitamente hanno a che fare con SharePoint dall’esterno, sono stati creati tre differenti gruppi di librerie. Vediamoli nel dettaglio:

1. Client Object Model – utilizzato da tutte le applicazioni windows, come applicazioni Windows Form, WPF, servizi, applicazioni console, ecc.. e rappresentato dalle librerie:

a. Microsoft.SharePoint.Client.dll (282 kb)

b. Microsoft.SharePoint.Client.Runtime.dll (146 kb)

Che possiamo trovare al percorso:
<Drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

2. Silverlight Client Object Model – utilizzato da applicazioni Silverlight e rappresentato dalle librerie:

a. Microsoft.SharePoint.Client.Silverlight.dll (266 kb)

b. Microsoft.SharePoint.Client.Silverlight.Runtime.dll (142 kb)

Che possiamo trovare al percorso:
<Drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin

3. ECMAScript Client Object Model – utilizzato all’interno di script javascript utili alle nostre personalizzazioni all’interfaccia di SharePoint e rappresentato da alcuni dei seguenti file:

a. CUI.js (344 kb)

b. SP.js (381 kb)

c. SP.Core.js (13 kb)

d. SP.Ribbon.js (208 kb)

e. SP.UI …

Che possiamo trovare al percorso:
<Drive>:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\ClientBin

Aggiungendo all’interno delle nostre personalizzazioni le referenze a queste librerie che, come potete notare, sono veramente leggere rispetto alle librerie del modello ad oggetti lato server (la Microsoft.SharePoint.dll pesa circa 8MB..), siamo in grado di “parlare” con SharePoint dalla parte del client, senza chiamare alcun web service e mantenendo un paradigma ad oggetti. Inoltre, questi modelli sono stati disegnati in modo da permettere agli sviluppatori di non trovare grosse difficoltà a passare dalla programmazione con il modello ad oggetti lato server, in quanto i nomi delle classi risultano molto simili a quelli delle classi utilizzate fin’ora (non è una regola precisa, ma in generale sono stati tolti i caratteri “SP” dai nomi della classi del API client-side). Alcune delle differenze sono visibili in questa tabella.

In breve, questi modelli ad oggetti per la programmazione di SharePoint lato client riescono a funzionare in quanto in ognuno di essi è stata costruita una classe proxy che si preoccupa di spedire richieste e leggere le relative risposte dal servizio WCF “client.svc” esposto da SharePoint 2010. Come potete vedere in figura, sia che io stia sviluppando una personalizzazione javascript, sia che stia lavorando con un’applicazione managed (quindi Windows o Silverlight), ogni richiesta fatta dalla classe proxy al servizio SharePoint viene formattata tramite sintassi XML ed ogni risposta ritorna invece in formato JSON, il che alza notevolmente le performance della nostra comunicazione tra client e server SharePoint, senza che noi dobbiamo procedere manualmente alla formattazione di richiesta o al parsing della risposta (come invece siamo sempre stati abituati sviluppando applicazioni che utilizzavano i web service di SharePoint Services 3.0).
Lato server poi, il servizio “client.svc” non fa altro che leggere la richiesta, utilizzare le classi del modello ad oggetti lato server per collegarsi al database dei contenuti ed esaudire quanto richiesto, per poi riformattare la risposta e rispedirla al client.

Per noi, tutto questo meccanismo è totalmente trasparente poichè trattiamo le informazioni di SharePoint utilizzando un modello ad oggetti che nasconde tutta la parte di serializzazione della richiesta e deserializzazione della risposta dal server.
A mio parere è veramente una gran bella novità questa.
Nel prossimo articolo vedremo come utilizzare le classi del Client Object Model all’interno di un’applicazione Windows per effettuare le operazioni di base di lettura, inserimento, aggiornamento e cancellazione di elementi in una lista SharePoint 2010.

Saluti Fabio