Dopo i primi due post introduttivi sul nuovo modello "App-oriented" introdotto in SharePoint 2013 (parte 1 e parte 2), volevo condividere con voi un po' di considerazioni. E' da un bel po' di tempo ormai che ho a che fare con questo nuovo modello e ci sono cose che mi piacciono e cose che non mi piacciono, soprattutto a confronto dell'esperienza maturata con le precedenti versioni del prodotto.

La prima cosa su cui voglio far caso è la linea guida data da Microsoft all'interno delle prime pagine dell'SDK di SharePoint 2013: "Develop an app whenever you can" (qui la fonte).

A mio avviso, questa è un'affermazione un po' troppo forte ora. Lo sviluppatore SharePoint è abituato al modello classico di sviluppo delle proprie personalizzazioni (praticamente dalla versione 2003 di SharePoint, quindi più di 10 anni fa) e prendere questa frase come legge forse è sbagliato.
E' vero che ci sono un sacco di improvement dati da questo modello, perché, se ci pensate bene, stiamo dando ai nostri Farm administrator una soluzione pressoché sicura per il loro ambiente (un po' di codice javascript o un redirect ad un'altra web application, esterna a SharePoint, non possono certo nuocere a nessuno), una soluzione facile da gestire (grazie alla presenza del marketplace e dell'app catalog interno) e, soprattutto, facile da migrare da un server all'altro in caso di migrazione di SharePoint ad una nuova versione o in caso di semplice dismissione dell'attuale parco macchine. Inoltre, siamo così obbligati a pensare le nostre applicazioni per essere fruibili da differeti device, differenti piattaforme e per essere conformi agli standard attuali per quanto riguarda lo sviluppo sul web (velocità, alta user experience, assenza di postback, ecc..), il che porta le nostre soluzioni ad un livello sicuramente superiore in termini di impatto visivo e facilità d'uso per l'utente finale. Ma pensare di sostituire totalmente le Farm solution a favore dello sviluppo di un App è una follia pura. Ricordiamoci infatti che la maggior parte di questi accorgimenti li possiamo prendere anche sviluppando una Farm solution, come siamo stati abituati fin'ora.

Secondo me quindi, per prima cosa, è necessario capire bene l'entità della funzionalità che abbiamo bisogno di implementare, per poi decidere se utilizzare questo nuovo modello o se rimanere sul "classico". Alla fine è una scelta normale per un'applicazione web, quella di utilizzare una tecnologia o prendere particolari strade implementative in base ai requisiti che l'applicazione stessa deve soddisfare. Quindi non vi sto dicendo niente di nuovo.
Abbiamo bisogno di modificare fortemente SharePoint e i suoi vari componenti? Utilizzeremo una Farm solution!
Abbiamo bisogno di modificare l'aspetto grafico del prodotto? Utilizzeremo una Farm solution!
Abbiamo bisogno di interagire con dati e informazioni presenti in siti, site collection o web application differenti? Utilizzeremo sempre una Farm solution.

Questo perché le App:
- non hanno la possibilità di eseguire codice server-side su SharePoint (quindi non hanno la possibilità di utilizzare il classico server object model),
- hanno come scope solo il proprio sito (l'AppWeb di cui parlavamo nei precedenti post),
- non hanno alcun tipo di accesso al sito padre o ad altri siti nella gerarchia, altre site collection o altre web application (questo è vero in parte, perchè con il Client Object Model per Javascript ad oggi si riesce ad accedere al sito padre, ma credo che toglieranno questa possibilità)
- non possono quindi installare sul sito padre le nostre personalizzazioni (vedi master page, page layouts, ecc..),
- non possono utilizzare tutte le tipologie di personalizzazioni che siamo abituati ora ad utilizzare all'interno delle nostre soluzioni SharePoint 2010, ma ne possono utilizzare solo una parte (vedremo nel prossimo post la lista di quelle disponibili)
- non hanno la possibilità per l'utente finale di interagire con il contenuto dell'AppWeb (per capirci, non c'è possibilità di entrare in "visualizza tutto il contenuto"; a liste e document library si però) o di permettere la visualizzazione di tale contenuto dal sito padre.

Le App sono fantastiche per lo sviluppo di applicazioni e funzionalità mirate, che non hanno dipendenze dal "mondo SharePoint esterno", che possono essere curate a fondo per poi essere fruite da differenti browser e device fisici e per cui è possibile stabilire dei permessi sull'intera funzionalità esposta e non sul contenuto. Punto.
Esempi di applicazioni di questo tipo sono le varie applicazioni di ticketing, di gestione di un progetto, di tracking, di prenotazione risorse, ecc.. (per rimanere sul classico eh, ma anche qua non c'è limite alla fantasia).

Quindi, quando leggete la frase "Develop an app whenever you can" pensate, come sempre, che non è Microsoft che dovrà sviluppare le vostre applicazioni SharePoint, ma siete voi e voi solo sapete qual è la via migliore da prendere per la vostra applicazione :)

Un'altra questione su cui vorrei fare attenzione invece sono le "Self-hosted" apps. Al contrario delle "SharePoint-hosted" apps, per cui possiamo sfruttare tutte le meraviglie e le facilitazioni che ci da la piattaforma, con questa tipologia di applicazione dobbiamo farci carico (noi e/o il provider che scegliamo per hostare le nostre applicazioni) di un po' di cose che forse ancora non avete chiare (quanto meno dalla documentazione fin'ora disponibile, non lo sono).
Innanzitutto dobbiamo mantenerne la disponibilità. Il che significa che c'è un lavoro doppio per mantenere disponibili sia la farm SharePoint sia il web server che fruisce l'applicazione agli utenti finali. Se utilizziamo la stessa macchina, dobbiamo preoccuparci solo di IIS fondamentalmente, ma se scegliamo un'altra macchina o un hosting esterno, allora è tutta un'altra questione perché dobbiamo preoccuparci di applicare politiche di backup, di effettuare una gestione della memoria e del disco, di effettuare analisi degli accessi e si tutto quanto concerne la fruizione di un'applicazione web in piena regola . Poi, dobbiamo preoccuparci di fornire un meccanismo di multi-tenancy per la nostra applicazione. Questo perché, una volta messa sul marketplace o sull'app catalog interno alla farm, l'applicazione può essere installata (quindi utilizzata) da siti differenti. Il che significa che dobbiamo scrivere il codice per permettere questo utilizzo multiplo.
Inoltre, dobbiamo pensare dove e, soprattutto, come salvare i dati di cui l'applicazione stessa ha bisogno per esporre le proprie funzionalità. Cose che invece, utilizzando SharePoint come piattaforma host delle nostre app, abbiamo già pronte.
Queste chiaramente, sono tutte considerazioni che bisogna fare prima di immettersi nello sviluppo di una "Self-hosted" app in SharePoint 2013.

L'ultima cosa non riguarda proprio il modello di programmazione, ma più che altro la risposta che possono avere gli utenti finali una volta che si approcciano a questo nuovo modello.
Infatti, come vi dicevo, ora è diventato tutto un'app. Se devo creare una nuova lista, faccio click sull'azione "add an app", se devo creare una nuova document library, vado sempre su "add an app", se devo utilizzare un'applicazione vera e popria, sempre su "add an app". Il che, per tutti gli utenti che sono abituati all'utilizzo di SharePoint, è probabilmente un po’ confusionario.
Ho chiesto il perché di questa scelta ad Andrew Connell, durante uno dei suoi web cast riguardanti questo nuovo modello e la risposta (purtroppo) è stata: "it's a marketing decision by Microsoft". E' probabilmente una scelta azzardata, ma penso proprio che ci dobbiamo abituare al cambiamento.

In ogni modo.. questo nuovo modello ha certamente dei concetti e delle caratteristiche molto belle ed innovative che, assieme alla presenza del Marketplace, sono sicuramente delle cose che meritano attenzione e su cui dobbiamo prepararci per avere così le idee chiare riguardo l'ampia scelta che abbiamo noi sviluppatori SharePoint 2013 al momento di iniziare lo sviluppo di una nuova applicazione.

Nel frattempo, qualcuno ha già iniziato a mettere qualche bell'esempio su codeplex:
- http://corporatenewsapp.codeplex.com/
- http://apps.codeplex.com/