Per SharePoint o non (come base per lo sviluppo di applicazioni) (vs ASP.NET)

Ho un POV che dovresti utilizzare solo SharePoint per lo sviluppo di applicazioni in queste condizioni.Per SharePoint o non (come base per lo sviluppo di applicazioni) (vs ASP.NET)

1) L'applicazione utilizza documenti e questi documenti richiedono una sorta di funzionalità che SharePoint fa estremamente bene (ricerca/indicizzazione, sincronizzazione con Outlook, ecc ...) Se tutto ciò che si desidera è un bucket di documento e un elenco, quindi ASP .NET o ASP.NET MVC.

2) L'applicazione deve utilizzare flussi di lavoro o flussi di lavoro personalizzati. Nessun flusso di lavoro quindi guarderei nuovamente ASP.NET o ASP.NET MVC.

3) La società deve essere disposta a dedicare almeno uno sviluppatore a tempo pieno a SharePoint. Non 1/2 o 1/3 di uno sviluppatore. È necessario impegno e attenzione per eseguire correttamente lo sviluppo di SharePoint. Devi bere il Kool-Aid. Se non si è disposti a specializzarsi in SharePoint, ma solo disposti a dilettarsi, le soluzioni risultanti sono terribili (IMHO). Ancora meglio se puoi dedicare due sviluppatori o un team (pensa a supporto/manutenzione/competenza/specializzazione).

Quindi cosa ne pensi?

nota: Penso che tutti i negozi di Microsoft dovrebbero utilizzare le funzionalità out-of-the-box di SharePoint se la loro azienda ha scelto di associare che con Exchange come parte della loro architettura collaborazione. Non sono anti-SharePoint.

UPDATE
Dopo la seduta in un workshop SP ho imparato che flusso di lavoro SharePoint è applicabile solo su base voce dell'Elenco per SharePoint. Pertanto, se il flusso di lavoro non utilizza gli elementi dell'elenco di SharePoint, probabilmente si dovrebbe considerare la base di .NET Workflow o qualcosa di personalizzato. Considera questo un sostituto del mio articolo n.

fonte

2009-07-24 MJLefevre

+1 Ascolta, ascolta !!! –

Penso che parte della ragione per cui i progetti devono essere la soluzione giusta per SharePoint è il modello di sviluppo. Come la distribuzione del codice nel GAC e il riavvio del pool di applicazioni. Dolore al collo su un grande server intranet aziendale SharePoint. – MJLefevre

Sono d'accordo. Attualmente Sharepoint (moss 2007/wss 3.0) rende l'elaborazione personalizzata un processo molto doloroso e lento. L'unico punto su cui non sarei d'accordo è la parte del flusso di lavoro. A mio parere, il flusso di lavoro in SharePoint è quasi inutilizzabile e dovrebbe essere evitato. Se stai per fare flussi di lavoro, vai su k2: blackpearl o MassTransit per l'opzione open source free.

fonte

2009-07-24 14:22:53

Mi permetta di chiarire. Non ho detto che il flusso di lavoro SP era fantastico. Volevo solo dire che se la tua app non ha un flusso di lavoro, perché non utilizzare ASP.NET? Tra l'altro, quello che è successo a Mass Transit. Il progetto è ancora molto attivo? +1 al lento e doloroso. – MJLefevre

Sì, MassTransit è ancora attivo. Uno degli sviluppatori principali di Chris Patterson è qui a Tulsa e la società per cui lavora per i suoi sistemi di produzione interni, quindi anche se non ha colpito la v1.0 penso che sia piuttosto stabile ... –

Ora spero che MSFT risolverò molti dei punti critici del dev nel 2010. Ho una piccola speranza che fare degli sviluppatori personalizzati nel 2010 sarà una proposta di valore molto migliore. –

Supponiamo di disporre di un data warehouse che raccoglie dati da più punti dell'azienda. Spero che tu abbia alcune dimensioni che hanno gli uomini d'affari designati come "proprietari di dimensioni". Queste sono le persone che hanno un interesse nell'organizzazione dei dati nella dimensione. Sono responsabili di mantenere aggiornate le gerarchie e gli elenchi, ma queste raccolte non sono popolate con dati operativi provenienti da sistemi transazionali, sono termini aziendali e gruppi e descrizioni che l'azienda parla. Questo è il loro naturale linguaggio commerciale. East Sales Team, Small Business, High Risk, promozione Print-Ad-25, ecc. Il punto in cui si trova il data warehouse è costituito dal 99% di operazioni/transazioni, ma è l'organizzazione aziendale che rende tutto più ragionevole per gli utenti e serve posto per catturarlo.

È sicuramente possibile creare un'app Web. Puoi usare un file Excel. Qualunque cosa. Ma puoi anche usare un elenco di SharePoint. Dove SharePoint è attraente per questo è quando l'ambiente esiste già (e quindi SUPPORTATO), quando i tuoi requisiti non sono estesi, cioè l'integrità referenziale non è richiesta, non hai le risorse per creare una nuova app web, gli utenti aziendali sono già familiari e confortevoli con SharePoint, ne hai bisogno ieri, ecc.

Quindi non sto parlando di scrivere codice e compilare librerie da installare su SharePoint. Sto solo cercando di presentare un ragionevole "momento e luogo giusto" per poter essere utilizzato.

BTW - Ecco un utile how-to on pushing and pulling data between SharePoint lists and SSIS.

fonte

2009-07-24 15:21:31

Posso vedere da dove vieni. Ma in 4 settimane puoi arrivare abbastanza vicino alla duplicazione della funzionalità di base dell'elenco in SharePoint. E poi hai il controllo TOTAL sull'app. Non devi lavorare attraverso un'astrazione su cui non hai controllo. Spero che MS faccia qualcosa per rendere più facile l'estrazione dei dati da una SP List. Se questa è una parte fondamentale della strategia di Microsoft, ottenere i dati dovrebbe essere facile come ODBC. +1 Buono arguemnt e collegamento – MJLefevre

Se si utilizza uno strumento personalizzato come MetaMan, l'utilizzo di SP come data surfacer per i dati aziendali è molto più rapido rispetto alla codifica personale. Ma perdi molto controllo nel modello SP. –

Perdere un sacco di controllo e $ utilizzando il BDC. Forse se il BDC fosse gratuito o parte standard di SP sarebbe più convincente. Su una tangente, non ha senso caricare per Excel Services (non sono molto buoni). Mi piace davvero il modo in cui la ricerca di SharePoint funziona su dati BDC. +1 a Microsoft su questo. – MJLefevre

SharePoint deve essere utilizzato come base per la collaborazione degli utenti aziendali (archiviazione, ricerca e modifica di altri documenti). Utilizzare SharePoint solo per lo sviluppo di applicazioni fa male e richiede il punto 3 fatto nella domanda.

Per lo sviluppo di applicazioni, preferisco utilizzare SharePoint come un portale Web che indirizza gli utenti all'applicazione o ospita la sua interfaccia Web (tramite controlli utente, webparts e simili) (oh aspetta, sono pronto a dire che SharePoint era un web portale).

fonte

2009-07-26 07:30:59 Nat

Immagino che questo significhi che siamo d'accordo. Mi piace l'idea di usarlo out-of-the-box, ma per lo sviluppo personalizzato hai davvero bisogno di un esperto e di una strategia. – MJLefevre

+1 sul punto host. Personalmente, sono un grande fan del "modello iframe" dello sviluppo di SharePoint. – MJLefevre

Anche senza documenti, è comunque possibile utilizzare Sharepoint come piattaforma per un portale con webparts personalizzate (alcuni dei quali sono basati su librerie di documenti del sito). È una buona piattaforma di portale e il mio portale di ricerca per le aziende è basato su sharepoint e funziona piuttosto bene. La cosa buona è che con questo portale sharepoint basato su webparts, puoi comunque occuparti di problemi di autorizzazione e problemi di personalizzazione della presentazione (trascina la web part in una particolare zona ecc., Che gli utenti fanno molto, btw) relativamente facilmente. Inoltre, le webparts di tipo WSRP funzionano molto bene con Sharepoint.

E hai ragione, solo se disponi di buoni sviluppatori Sharepoint, quindi ti semplifica le cose ed è una piattaforma decente, documenti o nessun documento.

fonte

2009-09-01 15:31:22 desigeek

Per SharePoint o non (come base per lo sviluppo di applicazioni) (vs ASP.NET)

risposta

Problemi correlati