SharePoint 2010 - Best Practices: come gestire assembly [discussione]

Question

C'è una discussione che è andata avanti per gli anni server durante la programmazione per SharePoint.

In Visual Studio è possibile aggiungere una soluzione SharePoint, che verrà convertita in un file .wsp per la distribuzione. Questo file .wsp conterrà tutti i file di montaggio richiesti.

Come si guida i file di CodeBehind per: ricevitore evento, ricevitore di funzionalità, pagina ASPX?

Posiziona questo file .cs all'interno della cartella SharePoint? (In questo modo dovrai distribuire un .dll da You SharePoint Project Aswell)

o sposta tutta la logica del codice in uno (o più) diversi progetto (i librerie di classe)?

Cosa fai ad esempio nel secondo esempio:

.
• Fare clic con il tasto destro, aggiungi nuova voce, ricevitore evento
• Sposta il file .cs in un progetto diverso
• Modificare le informazioni di assemblaggio all'interno del file elements.xml

  Nel primo esempio non spostiamo questi file, tenerli solo come VS2010 aggiunge loro.

  Non sto dicendo in che modo preferisco, voglio solo ricevere un sacco di input. Non dire solo "L'opzione 2 è cattiva". Mi piacerebbe davvero sapere perché e perché no!

  Grazie

  Modifica:

  La mia domanda qui non ha nulla a che fare con le estensioni ecc.

  Sto parlando di assicurarti che la tua soluzione SharePoint non contiene alcun file .cs. In questo modo non deve essere un assemblaggio nel GAC per questa soluzione.

  Esempio: ho customert.sps.intranet.solution (= la soluzione per generare wsp, quindi una voce di progetto Vuota SharePoint).

  Se aggiungo semplicemente una funzione e un ricevitore funzionalità, viene generato un file .cs e (dopo la distribuzione) un file cliente.sps.intranet.solution.dll è posizionato all'interno della cache di assembly globale.

  Questo è ciò che alcune persone non vogliono avere !!! (Non capisco perché, è per questo che sto chiedendo alcune opinioni).

  Per risolvere questo, creano un progetto all'interno di questa soluzione denominata: "customer.sps.intranet.logic", questa soluzione conterrà tutti i file di codici ricevitore funzionalità.

  Ciò significa che dobbiamo modificare il file Template.xml funzionalità per utilizzare la classe del ricevitore situata nel progetto "Logic". In questo modo manteniamo il "cliente.sps.intranet.solution" pulito e lo useremo solo per il packaging. Quindi non ci sarà un assemblaggio implementato al GAC denominato "customer.sps.intranet.solution.dll" ... invece un cliente.sps.intranet.logic.dll assembly viene distribuito su GAC.

Answer 1

Aaah, la questione eterna di soluzioni e DLL. :-) Perché si dividono, perché no, e quando? Non sto lavorando ATM, sono in vacanza, ma come mi hai chiesto di dare un'occhiata, riassumerò pochi take-away e il mio prenderlo. Quindi la mia risposta è basata sull'esperienza personale e sull'esperienza personale. (Scusa STACKEXHANGE)

X Non dividere "Codice dietro" e l'UI porta al codice difficile da mantenere. Qualcosa che ho visto su diversi progetti è che gli sviluppatori inesperti non affrontano bene con "Codice dietro" (classi C # accanto a XML / ASPX) tendono a scrivere più logica nel codice dietro in quanto hanno accesso diretto all'UI. Su un particolare progetto ho visto una "nuova" pagina di 1500 linee (che è già enorme) e la pagina "Modifica" è stata fondamentalmente una copia-and-incolla della nuova pagina. Certo che questa è "cattiva programmazione", non è inerente a mettere il codice dietro gli artefatti. Ma le cattive abitudini sono difficili da cambiare e questo modello di lavoro può aiutare a peggiorare le cose. In questo caso, la classe CS prima come controllo e avendo una specie di classe ereditata per la classe di modifica, sarebbe stata più facile da mantenere. Una volta creata, è possibile effettuare le pagine Asps ereditare da queste classi.

x Non si dividono "Codice dietro" e l'UI conduce alle classi con troppa logica. Un'altra cosa su quel progetto è che sia la nuova pagina come la pagina di modifica con connessioni dirette ai database SQL esterni. Hanno usato connessioni dirette SQL che hanno creato un sovraccarico in codice e manutenzione. Un approccio stratificato avrebbe aiutato molto.

x Un'applicazione a strati ha bisogno di assiemi separati. Bene, la stratificazione è buona! Hai bisogno di un assieme separato per questo? Non necessariamente. È possibile raggruppare la tua logica, la strato di accesso dati ecc. In cartelle / names spazi separati all'interno del proprio assemblaggio. Anche quelli sono strati. "Ma perché dovrei dividerli?" Tende ad essere buone pratiche. Perché? Beh, eviti l'uso accidentale di logica più profonda (ad es. Connessioni SQL), poiché quella logica è referenziata solo in un livello DA. Un altro vantaggio è che è potenzialmente più facile sostituire i livelli principali da un altro livello. Dì un'altra interfaccia utente o un'interfaccia mobile. Puoi spingerlo ancora ulteriormente e creare strati inferiori più generici, in modo da poterli usarli in seguito. Ecco come possono essere creati Nibernate e EF Frameworks.

X "È carino, ma è solo uno sviluppo ASP.NET." Giusto, ma gli stessi principi e idee possono essere utilizzati durante lo sviluppo di manufatti di SharePoint, come i ricevitori. Perché non lavorare per i ricevitori generici che possono essere parametrizzati con le proprietà delle funzioni o le proprietà della cartella? Riutilizzare la logica risulta principalmente in soluzioni più stabili.

X Separando i test incoraggia (unità). Una volta che inizi a separare e creare una classe più generica e così via, non è più una lunga elasticità utilizzare interfacce e modelli. Ciò significa che il test unitario sarà più facile da implementare (anche se dovremmo effettivamente usare TDD), come possiamo deridere più facilmente. Guarda il quadro MVC e come le cose ci sono ben separate. Funziona anche per SharePoint.

Pertanto per riassumere il mio 2C (e un cambiamento ;-)), puoi usare il codice dietro la marea direttamente sul tuo artefatto, ma preferisco no. Preferisco andare per il riutilizzo, il codice generico e testabile, che avere i ricevitori e il codice corrispondenti automatici per gli artefatti (anche se non è necessario modificare il modello di funzionalità XML nel caso manuale, poiché aggiungi il ricevitore della funzione nelle proprietà) e Fasci da localizzare (uso l'istante Vai da VS2010) ma alla fine è tutto su ciò che tu e il tuo progetto preferisci. : -)

Answer 2

In realtà, personalmente, non ha mai riscontrato una soluzione in cui i file da una soluzione di SharePoint sono stati spostati al di fuori di un progetto, tranne forse per situazioni in cui hai identificato pezzi riutilizzabili: ad es. Metodi di estensione, codice del gestore di eventi di base. C'è anche una ragione per non spostarlo, ad es. Di solito VS 2010 utilizza il GUID con le quali le classi sono decorate per il lavoro interno collega il gestore, quindi potrebbe accumulare correttamente le dipendenze. Inoltre, tutti i binari, sono comunque integrati, quindi il codice-accanto (non è già possibile crescere il codice in SP2010). Oltre alla registrazione di SafeControls (Web Parti Web, Controlli personalizzati, ecc.) Non sarebbe stato registrato correttamente come Visual Studio potrebbe includere Assemblee esterne nel pacchetto, ma non avrebbe necessariamente esplorato tali assemblee per il codice attuale - dovresti fare tutto questo Manualmente - cattivo per la produttività.

Queste sono riflessioni iniziali, potrebbero tornare con un po 'di più, ma la regola del basso: non stai riutilizzando quei pezzi - quindi meglio lasciarli dove vs propone. Piuttosto pianificare in anticipo che tipo di funzionalità si distribuisci, quali dipendenze hai, dispongono di ambiti, ordine di attivazione, ecc.

Spero che aiuti, C: \ MARIUS