Uso pratico del contenitore di iniezione delle dipendenze (IoC)

0

Sto creando un framework MVC-ish in PHP. Sto cercando di implementare un contenitore DI per consentire la creazione di oggetti controller (tra gli altri).

Il mio framework MVC è piuttosto tipico. Ogni modulo (o componente se lo si desidera) ha un controller responsabile dell'esecuzione delle richieste. Questi controller di modulo in genere estendono una classe Controller di base. Tutti i controller accettano Request e Response oggetti come argomenti.

La confusione si verifica perché alcuni controller potrebbero aver bisogno di argomenti diversi per funzionare. Ad esempio: molti controller avranno bisogno di un oggetto Database ; I controllori che inviano posta possono aver bisogno di un oggetto Mailer ; mentre un controller che registra i dati potrebbe aver bisogno di un oggetto Log . Il contenitore DI conterrà le ricette per la creazione di tutti questi controller.

Il mio front controller deve essere in grado di creare uno di questi oggetti controller, come specificato da una richiesta. Inoltre, ogni controller deve essere in grado di creare qualsiasi altro controller.

Come faccio ad avere il controller anteriore e i controller del modulo per accedere al contenitore DI in modo che non provochi una dipendenza dal contenitore DI da parte di ciascun controller?

In realtà non mi importa se il front controller dipende dal contenitore, sono più preoccupato per i controller del modulo.

Grazie,

    
posta Ron 09.02.2014 - 22:39
fonte

1 risposta

3

Dovrai avere quella dipendenza dal contenitore DI da qualche parte. Se è il front controller, bene, ma assicurati che il front controller sia il punto di origine unico per tutti gli altri controller. Tutti i controller dovrebbero essere creati qui.

Il tuo contenitore DI dovrebbe essere abbastanza intelligente da risolvere le dipendenze a una profondità illimitata. Qualsiasi dipendenza che un controller potrebbe avere verrà risolta dal contenitore e iniettata nel controller. Se anche uno qualsiasi di questi oggetti ha delle dipendenze, dovrebbe essere risolto dal contenitore.

Secondo me, questo è un buon approccio per diverse ragioni. Ti dà un modo di rimuovere le chiamate ai localizzatori di servizi o alle fabbriche. In qualsiasi classe che usa il framework, devi solo preoccuparti di ciò che sta facendo questa classe, e puoi tranquillamente pensare che tutto ciò che serve sarà fornito. L'altro vantaggio è che puoi condividere cose attraverso i componenti. Il tuo controller e un altro componente possono riutilizzare la stessa istanza di un repository db o qualcosa del genere. E, naturalmente, c'è la testabilità che porta DI.

    
risposta data 09.02.2014 - 22:55
fonte