Devo evitare lo sviluppo di SharePoint in Visual Studio?

La modifica della funzionalità in SharePoint potrebbe non richiedere la "conoscenza della programmazione", ma nella mia esperienza la maggior parte degli utenti deve essere altamente informata per comprendere realmente gli altri modi per modificare SharePoint, come SharePoint Designer e Dashboard Designer. Penso che se si può inserire la funzionalità in modo nativo in SharePoint (come BCS), allora questo fornisce schermate CRUD per i dati esistenti, il supporto del flusso di lavoro e altro ancora. Con il 2010 questo è un vero risparmio di tempo una volta che tutto è impostato correttamente, che può richiedere mesi .

L'incentivo in una società di consulenza di SharePoint è di fatturare quante più ore possibili per aumentare i profitti. Ottieni più ore fatturabili dai clienti che richiedono lavoro. I client richiedono più lavoro da un'azienda SharePoint se la maggior parte della loro funzionalità è legata a SharePoint. SharePoint rende le cose facili per gli utenti con il compromesso che lo sviluppo richiede più tempo (yay! Più ore fatturabili per l'azienda!). C'è un mezzo felice da incontrare e il valore di tale lavoro varia molto da situazione a situazione, quindi la compagnia non si siede e fa una discussione onesta dicendo ciecamente "mettilo in SharePoint!", È una bandiera rossa che è meno sul cliente e altro sulla bottom line.

Il motivo per cui dovresti sviluppare in Visual Studio è che quello che dovresti veramente generare sono le piccole soluzioni WSP che possono essere implementate da

Dev - > Staging - > Produzione

Hai anche la soluzione dei pacchetti, che si tratti di un processo timer, un modello di elenco, un gestore eventi, un modello BCS, una web part ecc. che puoi riutilizzare in tutto l'ambiente.

Con SharePoint Designer lavori dal vivo sul server e non stai creando componenti riutilizzabili.

Non tutto può essere fatto in modo nativo in SharePoint. Chiunque dica che non conosce SharePoint molto bene.

Detto questo, ci sono molte cose che possono essere fatte è solo una questione di ciò che vuoi che faccia. SharePoint è come uno strumento di potere degli utenti uber (pensa ad Access on the web) in modo che possa essere semplice come un elenco TODO per un'intera applicazione Enterprise che si intromette con sistemi esterni e tutto ciò che si trova in mezzo.

C'è molto che può essere fatto fuori dagli schemi, quindi sfruttalo. Ad esempio, se stai creando una soluzione che richiede contatti, utilizza il modello dell'elenco contatti come è fatto per te (potresti dover / dover aggiungere altre colonne) e integrarlo in Outlook.

SharePoint ha ciò che considero tre livelli di personalizzazione.

Il livello 1 è la configurazione OOTB. La semplice creazione di elenchi personalizzati con colonne personalizzate e viste personalizzate può essere effettuata nel browser con una scarsa conoscenza di come SharePoint funziona eppure ha un grande impatto.

Il livello 2 è quando apri la finestra di progettazione di SharePoint e inizi a creare visualizzazioni XLST personalizzate utilizzando web part DataView, JavaScript / jQuery personalizzato per migliorare l'esperienza utente o integrare funzionalità mancanti (come elenchi a cascata, compilando automaticamente moduli con determinati valori dinamici, ecc.)

Il livello 3 è una personalizzazione completa utilizzando il codice gestito .NET. Azioni personalizzate del flusso di lavoro di progettazione SharePoint, parti Web personalizzate, gestori di eventi. Lo chiami, lo stai facendo qui.

Mi piace bilanciare la vita di SharePoint vivendo circa il 60% nel livello 1, il 30% nel livello 2 e il 10% nel livello 3.

YMMV.

Anche se non hai intenzione di scrivere gestori di eventi personalizzati, pagine web, ecc. dovresti considerare l'utilizzo di Visual Studio per i motivi che dà Phil Duffy: è molto più semplice gestire il codice e, nel caso di XML, più facile per modificare in Visual Studio rispetto a designer SharePoint o NotePad per quella materia.