Come accendere / spegnere i moduli di codice?

Quanti moduli hai? Sono hardcoded?

Se ti trovi in un caso in cui hai solo dieci moduli possibili che vengono scritti una volta e richiedono l'intero aggiornamento dell'intera applicazione se devono essere aggiornati, puoi utilizzare facilmente controlli che si propagherà attraverso i modelli e verrà utilizzato dalle viste per regolare l'interfaccia utente (ad esempio mostrando o meno i collegamenti appropriati nel menu dell'applicazione Web).

Se, invece, ci si trova in un caso di molti moduli sviluppati da molti sviluppatori ed è inaccettabile richiedere l'aggiornamento dell'intera applicazione Web per aggiornare uno di questi moduli, allora dovresti cercare in plugins , come per esempio quello usato in FogBugz .

Per fare una scelta, considera i seguenti elementi, ordinati per importanza:

• Mantenibilità: è accettabile modificare il codice comune dell'applicazione web per modificare uno qualsiasi dei moduli?

• Dipendenze: alcuni moduli dipendono da altri?

• Prestazioni: poiché non conosciamo il contesto esatto, è difficile provare a prevedere l'impatto di ciascuna soluzione. Forse non ce ne saranno, se si utilizza la cache pesante e abilmente progettata.

• Architettura generale: se ci sono ragioni per fare qualcosa di monolitico (a causa delle interdipendenze), la prima soluzione sembra più appropriata; questo non è il caso se ogni modulo è rigorosamente separato dagli altri.

Questa è la ragione per cui sono stati costruiti framework come Managed Extensibility Framework (MEF) .

Usando MEF, ogni modulo opzionale risiede nella sua DLL e il tuo programma principale carica le DLL applicabili in fase di runtime. Hai solo bisogno di includere quelli per ogni particolare sito. Puoi quindi avere un modulo utente diverso da un sito all'altro.

Per me l'approccio più semplice sarebbe quello di impostare una tabella delle autorizzazioni e assegnare ad ogni modulo un identificatore. Un numero intero farebbe e avrà un modo per identificare quale sito è caricato e verificare su quella tabella per vedere se sono impostati per esso. Dove lavoro ora, lo facciamo nelle pagine poiché abbiamo più utenti con permessi e più paesi con cui fare i conti. Qualsiasi utente può avere moduli diversi e può utilizzare quei moduli in diversi paesi.

Fondamentalmente dichiariamo una variabile sulla pagina e cerchiamo i permessi degli utenti (quella parte è fatta nella pagina principale, quindi la facciamo solo una volta e la salviamo per la sessione). Ora dobbiamo solo controllare l'oggetto in memoria per vedere se hanno il permesso per quella pagina che è di nuovo in una variabile.

HTH

OP ha risposto alla sua stessa domanda in un modo. In molti CMS multi-homed, ogni "Sito" ha associato "Funzionalità". Alcune funzionalità sono "abilitate". Alcuni richiedono impostazioni individuali tramite 'featureConfiguration'.

Controlla l'utilizzo e le singole impostazioni di "featureConfiguration", di queste "funzionalità", perché avvengono in tutto il sito, devono essere eseguite una sola volta: all'avvio dell'app; quindi, può essere messo in cache su disco o su memoria come parte di "appSettings". Possono essere forzati ad aggiornare se le modifiche alle impostazioni li invalidano.

Ogni controller o pagina o controllo utente verrebbe adornato con un attributo o una proprietà che si dichiarava come membro di una particolare 'caratteristica', indipendentemente da quale parte di quel pezzo particolare suonava. Quando viene richiesto un pezzo decorato con una "funzione", è sufficiente verificare se sono abilitati, consentiti e configurati prima di continuare a caricare normalmente. In caso contrario, quindi reindirizzare quando appropriato con la notifica, o nel caso di un controllo, lasciare il segnaposto vuoto / vuoto, o aggiungere una notifica abbreviata sulla funzione non disponibile che altrimenti sarebbe lì - a seconda di ciò che è ideale per quel particolare pezzo .

Alcune parti (controller, pagina o controllo) potrebbero far parte di più funzioni, una 'funzione condivisa'. Ciò richiederebbe maggiore attenzione nel determinare se il contesto e la configurazione consentivano il caricamento.

Se le funzionalità dipendono dall'utente o dal ruolo, dovrebbero essere caricate solo una volta per sessione e devono essere modificate solo se durante la sessione le impostazioni sono nuovamente invalide e richiedono un aggiornamento forzato.

Bene. Tutti i moduli sono caricati in ogni momento. Non c'è modo di aggirarlo (se la tua applicazione è un'app Web).

Quindi devi controllare una bandiera, sempre che sia attiva o meno.

Se si utilizza ASP.NET MVC, è possibile farlo utilizzando un filtro azione che tagghi ogni controller con (+ una variabile di sessione). qualcosa come

[AuthorizeModule(1)] //<-- 1 = module id
public class MyController : Controller
{
}