Quali sono i concetti di sviluppo di SharePoint più difficili da comprendere per gli sviluppatori ASP.Net?

Question

Sto cercando di mettere insieme materiali di formazione su SharePoint 2007 (e, eventualmente, 2010) per sviluppatori ASP.Net esperti, e avendo fatto SharePoint per anni, non ricordo davvero dove fossero stati i punti peggiori all'inizio - per non parlare della quantità di contenuti di Google Googlable maggiore di un ordine di grandezza rispetto a due anni fa.

Detto questo, quali concetti di SharePoint sono i più difficili da comprendere e / o quali parti di SharePoint sono abbastanza esoteriche da non essere ovvie per uno sviluppatore di SharePoint principiante che si sta semplicemente immergendo?

Answer 1

Greg,

Nella mia esperienza, l'emissione relativa alla corretta eliminazione di oggetti ( SPWeb e SPSite oggetti che, a loro volta, fanno riferimento a SPRequest avvolgono COM non gestiti oggetti) sono un gotcha comune e la fonte di molti problemi di scalabilità, prestazioni e altri problemi di codifica. Una volta che Microsoft ha compreso la portata del problema e il grado di confusione degli sviluppatori in quest'area, hanno scritto un ampio articolo di orientamento ( http://msdn.microsoft.com/en-us/library/aa973248.aspx ) e sviluppato lo strumento SPDisposeCheck ( http://code.msdn.microsoft.com/SPDisposeCheck ).

Questo è il mio voto per " non ovvio per uno sviluppatore di SharePoint principiante che si sta semplicemente tuffando " : -)

Per quello che vale!

Answer 2

Il mio elenco di cose più difficili da comprendere sono:

• Sicurezza dell'accesso al codice e tutto il altre funzionalità di sicurezza
• Differenza tra sito / applicazione pagine e personalizzate / non personalizzate pagine
• CAML in entrambe le query e in tutte le definizioni
• Cosa c'è già in SharePoint così tu non reinventare la ruota

• Rinuncia al controllo.

  Non controlli quali web part sono su una pagina e come sono collegati. Dovresti solo renderli possibili riutilizzare

  Non controlli quale elenco si trova in a sito o quali campi contengono

• Mancanza di supporto per più lingue
• Non gettare SPWeb e SPSite se ottenerli da SPContext.Current
• controlli delegati

Altre cose nuove ma che sembrano essere più facili da capire sono:

• Soluzioni / caratteristiche
• Tutti i segnaposto nelle pagine master

Answer 3

* Mancanza di controllo *

Questo è il problema chiave come Per Jakobsen menziona . Andando avanti ...

1. Non è possibile accedere e modificare i file .aspx e .master ovunque tu voglia. Ci sono conseguenze come unghosting, supporto e che spesso non funziona come ci si aspetterebbe. Una buona comprensione di come SharePoint compone le pagine è fondamentale.

2. Non esiste un modo (supportato e affidabile) per interrogare direttamente il database. Ciò è estremamente frustrante per gli sviluppatori ASP.NET che sono abituati a progettare / lavorare con database appositamente progettati e ben progettati. Le query CAML non sostituiscono la potenza di query SQL ottimizzate.

3. (Più di un 2b): scarso supporto per i dati relazionali tra elenchi. Strano per un'applicazione enterprise.

4. Un po 'fuori tema, ma il markup HTML e CSS è stato un incubo nel 2003 e non molto meglio nel 2007. È doloroso lavorare con e non è neanche carino. Devi fare di tutto per produrre un sito pienamente conforme agli standard web e alle migliori pratiche.

Per riassumere, le cose di solito devono essere fatte "nel modo SharePoint". Questo spesso non è il modo più efficiente o elegante che preferisce un devoto ASP.NET. Agli sviluppatori piace l'eleganza e non piace rinunciare al controllo.

Ci sono anche dei gotcha proprio nel prodotto ( Sean ne ha menzionato uno chiave ) in agguato come piccoli fili per ignari. L'unico modo per conoscerli e capirli è conoscere SharePoint - ed è un grande prodotto.

Leggi altre discussioni a riguardo su Perché gli sviluppatori ASP.NET non usano WSS? su SharePointDevWiki.

Answer 4

Cosa c'è già in SharePoint in modo da non reinventare la ruota. Voto per questo.

Answer 5

Per ha coperto ha coperto la maggior parte dei punti per me, ma ne aggiungerò un altro:

1. SPContext - Il concetto di esecuzione di codice concettuale, ad es. Oggetto SPContext.Current o Properties in un ricevitore di eventi.

2. In seguito al contesto è anche importante capire chi è il codice in esecuzione e quindi quali azioni può completare - Elevazione (elevazione dei privilegi), Impersonazione (token) ed esecuzione (servizi web / ricevitori di eventi) .

3. Gestione degli errori - Tutti urlano quando l'unico errore emerso è "un errore si è verificato", quindi la comprensione dei registri SP e dei codici di errore è fondamentale. Questo è importante per ridurre il tempo perso a inseguire un errore XML esasperante.

4. Strumenti di Visual Studio - WSPBuilder, VS Tools per Sharepoint ecc. Riduci il dolore della distribuzione e del debug accorciando il ciclo di integrazione.

Answer 6

Crea report / dashboard utilizzando i servizi di reporting di SQL Server per problemi del mondo reale e mostrali nel sito sharepoint. Numero di esempi / tutorial trovati online non importa che la questione sia ancora insufficiente (immagino).

Answer 7

Tutto ciò che riguarda l'architettura e le implementazioni del mondo reale. Sono uno sviluppatore ma devo sporcarmi la mano se voglio avere il più vicino possibile ambiente client nei miei ambienti virtuali senza aspettare un supporto IT ufficiale. Prova a creare una piccola fattoria con intranet, internet, extranet, meccanismo di autenticazione mista, mapping di accesso alternativo, configurazione dell'intestazione host e così via. È un lavoro tutto dedicato, ma dovrai immergerti se vuoi sviluppare implementazioni di medie e grandi dimensioni.