Aggiunta di una fabbrica di controller a ASP MVC

Question

Ho un'idea di design per un grande progetto al lavoro e penso di averlo capito, ma mi piacerebbe davvero avere un feedback su a) l'idea in generale, eb) la mia proposta implementazione.

L'idea di base è semplice: voglio creare un'applicazione ASP MVC che possa essere estesa in futuro con controller e viste aggiuntivi senza dover ricompilare il codice. L'idea è di avere un'applicazione MVC con un set di funzionalità molto semplice e quindi estendere la funzionalità aggiungendo un altro 'Application.dll' che contiene controller, dati e business logic specifici per tale applicazione. nella stessa directory dell'applicazione MVC principale durante l'installazione

Il problema è che MVC esegue il routing sui tipi all'interno dello stesso assieme, quindi anche se si spostano le definizioni di instradamento nel database, MvcHttpHandler non è in grado di instradare qualsiasi cosa alla nuova DLL poiché non "conosce" i tipi di controller in esso. Guardando il codice MVC, ho scoperto che per caricare i controller si chiama semplicemente Activator.CreateInstance che appare solo nell'assembly corrente

La mia soluzione è semplice ma forse mi manca qualcosa: sovrascriverò MvcHttpHandler sostituendo direttamente ControllerFactory (non so come farlo) o duplicando quella funzionalità in una classe derivata. Il nuovo codice leggerà la richiesta e proverà a caricare il controller prima dall'assemblaggio corrente e poi da quello esteso. Una volta trovato il corretto assemblaggio, userò CreateInstance e lo passerò ad esso per ottenere il controller che voglio.

Answer 1

La fine di this article mostra come implementare il proprio ControllerFactory. Fondamentalmente, si deriva da DefaultControllerFactory e quindi lo si collega in Application_Start() nel proprio global.asax.

Answer 2

Non c'è niente di sbagliato nell'idea di una fabbrica di controller, a patto che sia semplicemente più flessibile in seguito. il problema è quando caricate i controller con il codice che appartiene ad altri livelli, il che è uno dei motivi per cui "avete bisogno" della flessibilità degli altri controller. Finché non si mischiano strati insieme, non vedo alcun problema con l'idea della fabbrica.