Sviluppo WSS / MOSS ... Dove disegnare la linea?

Question

La nostra organizzazione ha iniziato il percorso SharePoint circa due anni fa. Prima di ciò, noi (gli sviluppatori) abbiamo scritto principalmente front-end asp.net per back-end SQL. Ora sembra che ogni volta che nasce un nuovo progetto, ci viene chiesto di "adattarlo" a SharePoint; e abbiamo inserito alcune cose in SharePoint che probabilmente avrebbero dovuto essere applicazioni singole o applicazioni web a causa della complessità e delle interazioni con altre tecnologie.

La mia domanda è: dove tracciate la linea per lo sviluppo di un progetto in SharePoint rispetto all'applicazione Web / Winform e in che modo convincete i vostri manager che SharePoint potrebbe non essere la soluzione migliore per un particolare progetto?

Answer 1

Sono in qualche modo d'accordo con te sul fatto che a volte questa è una domanda difficile. In generale, tuttavia, sono d'accordo con il cliché che devi solo pensare a un'app sharepoint in modo leggermente diverso. Se i tuoi dati possono essere considerati come basati su elenchi, probabilmente SharePoint non è un framework di sviluppo necessariamente scadente. Può sembrare più lavoro in superficie, ma le sfide dell'IMO si spostano da un luogo all'altro. Se si utilizzano elementi come modelli di campi personalizzati e web part, è possibile gestire in modo relativamente naturale tutti i tipi di dati. E ottieni gratuitamente gli aspetti positivi di SharePoint (un framework di sicurezza già maturo, ricerca integrata, modelli / definizioni di siti ed elenchi, personalizzazioni di pagine personalizzate, yada, yada).

Anche io non so cosa intendi per "complessità e interazioni con altre tecnologie" qui, quindi è difficile immaginare quali problemi specifici potrebbero essere introdotti quando SharePoint viene aggiunto al mix.

Se il tuo team di sviluppo è relativamente inesperto con SharePoint e ti preoccupi della qualità e delle scadenze, posso sicuramente capire il tuo punto. Non è una curva di apprendimento facile, ma penso che il prodotto SharePoint sia estendibile in modo più naturale di quanto molte persone gli attribuiscano il merito.

Answer 2

Esiste, in alcuni casi, una terza opzione tra un'applicazione di SharePoint e un'applicazione ASP.NET. È possibile creare pagine di siti e applicazioni personalizzate e distribuirle in un sito di SharePoint. (Il libro Inside Windows SharePoint Services 3.0 offre una buona panoramica di come eseguire questa operazione.) Ciò consentirà di utilizzare ASP.Net e SQL Server in un ambiente SharePoint (il che significa che è possibile sfruttare anche vantaggi come la sicurezza di SharePoint). Non è facile come sviluppare una semplice applicazione ASP.Net, ma è un compromesso.

Naturalmente, questo è una specie di tecnicismo se vogliono che queste nuove applicazioni siano costruite su tecnologie SharePoint (elenchi, librerie, flusso di lavoro, ecc.), non solo per essere "dentro". SharePoint.

Answer 3

Uno dei motivi principali per cui potresti inserire un'applicazione in SP è quando vuoi sfruttare i blocchi che SP ti offre:

• Sicurezza (condividi la sicurezza con il sito)
• Dati (archivia alcuni o tutti i tuoi dati negli elenchi)
• Provisioning (se vuoi la tua app su più siti)
• Interfaccia utente con alcuni dati di base, ad es. Le liste ti danno questo e non devi costruirlo.

Answer 4

Una cosa da considerare quando si cerca di "integrare" una nuova app nel pool esistente è se ci sono sovrapposizioni di dati (clienti, inventario, ecc.) che trarrebbero beneficio dalla fusione.

Vi è anche il vantaggio di poter eseguire il backup di più applicazioni e di tutti i rispettivi dati in un unico posto.

Answer 5

Perché chiedono che tutto vada in SharePoint?

Nella mia esperienza è perché l '? intranet di SharePoint ole è ottima come portale per mantenere tutto insieme e reperibile sotto un'unica architettura di informazioni.

Affronta il problema da una percezione degli usi dello spazio dell'applicazione nell'organizzazione.

Fintanto che l'applicazione appare e si sente come parte del sito Intranet e l'utente non deve pensare a come raggiungerlo (e come tornare indietro), puoi praticamente prendere qualsiasi decisione sull'architettura necessaria per ottenere il miglior rapporto qualità-prezzo per le organizzazioni quando si tratta di implementazione e manutenzione.

Quando abbiamo iniziato a pensare al sito meno da SharePoint rispetto ad altre cose ai simpatici concetti lanosi di Architettura dell'informazione, reperibilità e usabilità, le nostre decisioni di non renderlo effettivamente all'interno di SharePoint, ma ancora lo skin come l'Intranet sono diventate più facili da vendere .