Il nuovo App-Model di SharePoint 2013 - Parte 1

Come vi dicevo, SharePoint 2013 vede moltissime novità per noi sviluppatori. Prima fra tutte, il nuovo modello App-oriented, per la costruzione di applicazioni personalizzate basate sulla piattaforma di collaborazione Microsoft.

Questo modello va aggiunto a tutto ciò che già conosciamo noi sviluppatori SharePoint. Infatti, per fare un pò di chiarezza rispetto a quello che si legge in giro (ed anche un pò per rassicurare chi di voi ha investito tanto su SharePoint 2010), è bene notare che tutte le skill che abbiamo acquisito fin'ora per quanto riguarda lo sviluppo di personalizzazioni SharePoint, sono ancora totalmente attuali. Il modello orientato alle App è solamente un'aggiunta per dare al prodotto una nuova veste e per cercare di farlo affermare ancor di più come piattaforma applicativa a 360 gradi. Inoltre, come vedremo, capirete che avrete la possibilità di riutilizzare gran parte delle vostre conoscenze per la scrittura delle vostre App.

In ogni modo, per fare un po’ di riepilogo sull'offerta attuale di SharePoint 2013 per noi sviluppatori, abbiamo la possibilità di utilizzare:

• Farm solutions (o soluzioni di tipo full trust): presenti dalle prime versioni di SharePoint, ci danno la possibilità di installare una personalizzazione a livello di Farm. Quindi possiamo interagire con il file system, utilizzare il set completo delle API server-side di SharePoint ed utilizzare tutti i tipi di personalizzazioni fin'ora conosciute per la scrittura delle nostre applicazioni. Insomma: controllo completo!
  Da questo punto di vista, oltre ad arricchire notevolmente il server object model (escludendo però tutte le novità dei vari servizi tipo BCS, Search, ecc.. che vedremo in seguito), non sono stati fatti grossi cambiamenti.
  A mio parere, dobbiamo sicuramente continuare ad utilizzare questa tipologia di soluzione quando abbiamo la necessità di mettere in piedi applicazioni complesse, che hanno bisogno della presenza di tanti file sul file system e che estendono SharePoint in maniera veramente intrusiva.
  Un classico esempio di una personalizzazione che siamo obbligati a sviluppare tramite una Farm solution è sicuramente una intranet, in cui si devono fornire agli utenti finali una o più site definition, una grafica personalizzata, workflow, application page, dati presi tramite connessione al database, servizi WCF, ecc..
  
  
• Sandbox solutions: presenti solo da SharePoint 2010 e sfruttate per lo più su SharePoint Online (Office 365), ci danno la possibilità di scrivere personalizzazioni che girano in un contesto ben delimitato, con un set altrettanto limitato di API server-side. Anche in questo caso, sono stati fatti veramente pochissimi improvement a questa tipologia di soluzioni che, secondo me, verranno utilizzate sempre meno.
  Addirittura, nelle pagine attuali della documentazione, c'è scritto che in SharePoint 2013 le sandbox solutions sono state deprecate (vedi qua), anche se vi assicuro che è un errore di contenuto. Le sandbox solution devono considerarsi deprecate solamente a favore dello sviluppo di App, ma continuano comunque ad essere disponibili in SharePoint 2013 e in SharePoint Online 2013.
  In ogni caso, prendete sempre con le pinze queste scritte perché sono sicuramente soggette a cambiamento.
  
  
• Apps: disponibili SOLO su SharePoint 2013, ci danno la possibilità di scrivere specifiche applicazioni basate sugli standard web del momento (quindi HTML5, CSS, Javascript, OAuth, OData, ecc..), in grado di interagire con gran parte delle funzionalità enterprise che mette a disposizione SharePoint stesso, supportando così l'ambia gamma di dispositivi fissi o mobili presenti attualmente sul mercato ed estendendo la possibilità di integrazione anche a tutte le altre piattaforme, gli altri linguaggi e, più in generale, a tutti gli sviluppatori che normalmente rimanevano esclusi dal mondo SharePoint.
  Questo significa quindi che non abbiamo accesso al modello ad oggetti server-side di SharePoint per la scrittura dell'applicazione (vi prego, non vi spaventate eh :), ma contenuti e funzionalità del prodotto possono essere sfruttati all'interno dell'applicazione stessa tramite il Client Object Model (su cui è stato fatto veramente un lavoro notevole) o tramite i servizi REST (anche loro ampiamente evoluti).
  Assieme a tutto ciò, le proprie App potranno essere rese disponibili a tutti su un Markteplace, visibile a livello mondiale e previa verifica da parte di Microsoft ovviamente, o su un App catalog interno alla Farm, in grado di contenere le vostre App ed esporle alle varie web application, site collection e ai vari singoli siti.

Riguardo quindi questa nuova possibilità, come prima cosa secondo me è molto importante capire che questa nuova tipologia di personalizzazione di SharePoint deve essere vista e sfruttata per lo sviluppo di applicazioni che hanno un fine pratico ben preciso. Che risolvono un problema o che espongono una funzionalità puntuale. Un esempio lampante può essere la classica applicazione di richiesta ferie/permessi (giusto per farvi capire). Totalmente isolata rispetto al resto, che espone una singola funzionalità, con la possibilità di aver permessi a sé stanti e la necessità di essere fruibile tramite pc, tablet e cellulare, in modo da permettere anche a chi è fuori ufficio di fare richiesta per le proprie ferie.
Se dobbiamo invece modificare intensamente SharePoint, o abbiamo bisogno di alcune funzionalità esposte solamente dal modello ad oggetti server-side oppure, semplicemente, siamo più produttivi sviluppando una soluzione classica, sappiate che nessuno ce lo sta vietando.

Per cercare di spiegarvi ancor meglio di che si tratta quando si parla di App SharePoint ed anticiparvi alcuni dei vantaggi, pensate a tutte quelle applicazioni che vi è capitato di sviluppare esternamente a SharePoint stesso, ma che sfruttavano le sue funzionalità, le sue strutture, i suoi dati. Esternamente, perché magari volevate sfruttare il nuovo .NET Framework o perché magari avevate skill più forti su ASP.NET o perché avevate dei vincoli architetturali che non vi permettevano di installare soluzioni server-side all'interno della Farm. Applicazioni di questo tipo, ad oggi, erano totalmente staccate da SharePoint (proprio nel senso "fisico" del termine) e ne potevano sfruttare le funzionalità solo tramite chiamate ai web services esposti o, dalla versione 2010, tramite il Client Object Model.
Con SharePoint 2013, abbiamo invece un'architettura ben precisa a supporto dello sviluppo di questo tipo di applicazioni. Se ci pensate bene poi, personalizzazioni di questo tipo, a fronte di una migrazione di SharePoint potevano essere a loro volta migrate ma con minimo sforzo rispetto al lavoro che invece si deve fare per migrare una Farm solution.

Capiamoci bene però. Non sto dicendo che le App ora sono oro colato e il resto è diventato merda in un secondo.. anzi!
Dico solo che avrete modo di capirne le potenzialità e, soprattutto, capire quando scrivere un App oppure quando sfruttare una Farm solution. Parleremo di questo sicuramente in seguito, perché è un argomento molto importante.

Poi, il fatto che la nomeclatura generale per la rappresentazione di singole istanze si liste e document library sia cambiata (ora per creare una nuova lista di contatti, per esempio, si deve fare click sul bottone "add an app" e poi scegliere l'app relativa) è una cosa che anche a me non è piaciuta, più che altro perchè crea confusione con questo nuovo modello di soluzioni. Le app sono una cosa... liste, document library e web part sono un altra.
Quindi occhio a non fare confusione.

Dopo questa breve introduzione, continueremo nei prossimi post ad esplorare questo nuovo modello di programmazione fornito da SharePoint 2013.