Best practice per l'utilizzo di un controllo utente su molti progetti

Question

Best practice per l'utilizzo di un controllo utente su molti progetti

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

1

Ho un controllo utente di messaggistica, che viene utilizzato in 4 progetti, e per ogni modifica devo propagarlo in 4 punti. Questo è ovviamente contro il principio DRY . Tuttavia, la centralizzazione dei controlli utente non è un compito facile, perché hai sia markup che code-behind e sappiamo che il markup non verrà compilato fino alle richieste di runtime. Ciò significa che non puoi semplicemente inserire il controllo utente in un progetto, compilarlo e utilizzare il suo file DLL di risultati in molti punti.

Quindi, cosa suggerisci come un buon approccio per la centralizzazione dell'uso dei controlli utente?

dry asp.net user-control

posta Saeed Neamati 13.12.2011 - 08:52

fonte

3 risposte

Leggi altre domande sui tag dry asp.net user-control

Differenze tra symfony 2 e 1? Scegliere la lingua per scrivere la biblioteca generale in

score 4 · Answer 1

Crea un pacchetto NuGet per questo. Dovresti essere in grado di distribuire il markup e il codice nelle posizioni appropriate e gestisce qualsiasi modifica di web.config e gestisci l'aggiornamento di tutto questo come un'unità, con un pacchetto NuGet.

score 2 · Answer 2

I controlli utente non dovrebbero essere usati per centralizzare le funzionalità che i diversi progetti hanno in comune. Un modo corretto per creare componenti generali sarebbe quello di creare controlli server personalizzati . I controlli del server possono essere compilati in DLL e referenziati nei progetti che li utilizzano.

score 1 · Answer 3

Se hai creato un WebUserControl in un file .dll e lo hai creato .dll in una cartella del pacchetto di distribuzione in cui si trova comunemente, allora dovrebbe essere referenziato (da tutti i progetti) da quella cartella. In questo modo quando ogni progetto successivo che fa riferimento a questo file (indipendentemente dalla posizione del progetto sul file system locale) otterrà automaticamente l'ultima copia del file .dll da quella posizione. Il nostro team ha una cartella comune mantenuta relativa alla nostra cartella delle soluzioni globali che fa riferimento a tutte le librerie di terze parti e alle librerie aziendali comuni che trattiamo come se fossero librerie di terze parti.

I riferimenti vengono fatti a questa cartella e i progetti di applicazioni web useranno questo file per ogni build. Se si dispone di un progetto di sito Web, il file .dll allegherà un file .refresh ad esso. Finché il file di aggiornamento punta al percorso relativo indicato nella cartella globale, è necessario solo creare questo file una volta. Ogni successiva creazione di un progetto esterno includerà la nuova DLL automaticamente.

Ad esempio:

C:\Projects

C:\Projects\Common    <-- Store your dll here

C:\Projects\MyWebsiteProject

C:\Projects\MyWebApplicationProject

Fintanto che gli altri progetti fanno riferimento a C:\Projects\Common\MySharedControls.dll nello stesso modo in cui dovrebbero essere senza soluzione di continuità.