Valutazione di Sharepoint vs ASP.NET come piattaforma di sviluppo

Question

Sto valutando Sharepoint (non MOSS) rispetto a ASP.NET come piattaforma di sviluppo per una soluzione imminente per il nostro team. Svilupperemo una soluzione per un'ampia distribuzione (speriamo) in una varietà di ambienti. Sto identificando le categorie per valutare i pro/contro per ogni scelta di piattaforma. Ho selezionato categorie applicabili ai requisiti della nostra soluzione e che incideranno sulla produttività degli sviluppatori/tester. Qualcuno può pensare ad altre categorie che sarebbero appropriate per un confronto? Qualcuno può fornire dettagli sulle tue esperienze con le due piattaforme rispetto a una qualsiasi delle categorie?

Alcune altre informazioni, abbiamo un breve periodo di tempo di due mesi per rilasciare qualcosa, quindi stiamo dando la priorità alle funzionalità mentre parliamo. Vediamo Sharepoint come un modo per ottenere rapidamente qualcosa mentre sfruttiamo il framework UI per un'interfaccia utente, una sicurezza, elenchi e librerie di documenti di base per l'archiviazione.

ambiente di sviluppo

produttività degli sviluppatori

Testabilità funzionale

Developer Testabilità (unit test)

Role Based Security

Vista-based Security

User Experience

Database - Facilità di sviluppo con Sharepoint basato sull'utilizzo di elenchi. Tuttavia, l'aggiunta di report come requisito rende l'utilizzo di elenchi un ostacolo.

Report - Sharepoint rende questo difficile

Document Repository - La nostra soluzione richiede più raccolte documenti da allegare artefatti per elementi della soluzione

Imballaggio

Installazione - Sharepoint ci fornisce una facile installazione famr tramite WSP .

scalabilità

estensibilità

Complessità

concettuali Integrity (i confini del dominio)

Ridondanza Support/Replication/Backup/Recovery

Answer 1

Ufficialmente, al fine di sviluppare soluzioni WSS, tutti i tuoi sviluppatori avranno bisogno di far funzionare il loro ambiente di sviluppo su un server WSS. Lo considero negativo.

Vedere i numerosi commenti sotto Sharepoint tools support in Visual Studio di Somasegar.

Direi che dal momento che si ha una scadenza breve, si considera anche il fatto che esiste una comunità di sviluppatori SharePoint molto più piccola rispetto a una comunità ASP.NET. Confronta il numero di articoli su SO taggato con "ASP.NET" in contrapposizione a quelli taggati "SharePoint".

Vorrei andare con ASP.NET a breve termine, capendo che potresti essere in grado di refactoring della tua applicazione per utilizzare SharePoint a lungo termine. Utilizzare una struttura di database simile all'elenco o ad altri tipi di contenuto che avresti creato in SharePoint. Mantenere un modello di distribuzione simile. Sentiti libero di usare il flusso di lavoro, ma probabilmente dovrebbe essere parallelo alle caratteristiche del flusso di lavoro di SharePoint. Potresti anche disporre le tue pagine in modo simile. In questo modo sarà più semplice spostarsi in SharePoint quando avrai più tempo.

Answer 2

Non vedo costo.

Answer 3

La tua soluzione avrà qualcosa a che fare con la collaborazione o la gestione dei contenuti web? In caso contrario, aggiungere SharePoint nel mix non sarà una grande idea.

L'utilizzo di WSS 3.0 come piattaforma di sviluppo anziché ASP.NET richiederebbe una seria giustificazione e non è possibile distinguere dalla descrizione limitata della soluzione perché lo si potrebbe contemplare.

Su tutti gli aspetti di misurazione, la creazione di sviluppo sulla piattaforma SharePoint aggiungerebbe coplexity e quindi costi per qualsiasi sforzo di sviluppo.

Aggiornamento

vedo sicurezza Sharepoint, raccolte documenti, framework di interfaccia utente, e la mancanza di dover costruire e prova un DB così grande productivty esaltatori. Quelli sono Sharepoint caratteristiche che possono trarre grandi vantaggi da

I vantaggi di SharePoint per tali elementi sono di gran lunga superato dagli aspetti di costo di apprendimento, codifica e SharePoint di supporto. ASP.NET offre soluzioni semplici per questi articoli e in un modo molto più gestibile. Avendo usato entrambi i prodotti si vuole rimanere con ASP.Net

Ricordate che le elenchi di SharePoint non hanno alcun tipo di integrità relazionale in modo da creare qualcosa di più di un rapporto banale tra le liste in SharePoint finirà massicciamente più costoso creando una dichiarazione di join e alcuni proc memorizzati.

Senza conoscere ulteriori dettagli del progetto, non è possibile escludere completamente SharePoint come soluzione.

Mentre è possibile utilizzare SharePoint come piattaforma di sviluppo, se non si dispone di esperti di SharePoint che lavorano con te in grado di rispondere alla propria domanda, non si avranno sufficienti competenze SharePoint sul progetto per renderlo un successo.

Answer 4

scalabilità
Restrizioni della licenza
estensibilità
Complessità
concettuali Integrity (i confini del dominio)
profit lock-in/Open Systems Support
Ridondanza/Replication/Backup/Recovery Supporto

Answer 5

Utilizziamo SharePoint come componente per la maggior parte delle applicazioni che creiamo per la sua capacità di creare e gestire elenchi e tipi di contenuto (e auto-CRUD), controllo delle versioni, modello di autorizzazione e strumenti del flusso di lavoro.

Abbiamo sviluppato SLAM, SharePoint List Association Manager, per ovviare alle ovvie limitazioni in termini di dati di SharePoint non relazionali. Poiché invia i dati di SharePoint a SQL Server, ci consente di utilizzare SharePoint solo sul "back-end" con solo ASP.NET sul front-end, una configurazione che usiamo spesso.

Abbiamo rilasciato SLAM come progetto open source in modo che il resto della comunità di sviluppo possa trarre vantaggio da questo approccio e aiutarci ad estenderlo.

http://slam.codeplex.com

Felice Slamming!

Allan