Contenitore DI / IoC vs factory: dove configuro la mia applicazione e perché?


9

Sto cercando di capire quando utilizzare il registro DIC / IoC per configurare il mio software e quando utilizzare le fabbriche, insieme al ragionamento alla base di entrambi gli approcci.


Sto usando StructureMap come mio contenitore DI (DIC), che è facile da configurare usando i registri. Nel DIC praticamente tutti gli oggetti registrati sono statici, nel senso che non ho bisogno di cambiare / scambiare nessuna implementazione / istanza in fase di esecuzione, una volta che il DIC è configurato e sono configurati nel DIC come singoli. Tuttavia, poiché il mio software (SW) funzionerà su dispositivi diversi, ho bisogno di selezionare un registro specifico del dispositivo in base al dispositivo su cui il mio SW funziona per configurare l'hardware di conseguenza.

Poiché la costruzione di alcuni dei miei oggetti richiede la lettura nei file di configurazione, sto usando le fabbriche per restituire queste istanze al DIC, al fine di separare la lettura della configurazione dalla creazione dell'oggetto. Ho registrato i getter di fabbrica nel DIC per i tipi di plug-in corrispondenti.

Ora dì che ho un tipo di plugin IMotorcon tipi concreti Motor1e Motor2, che dovrebbe essere gestito da una fabbrica. Ora ci sono due modi in cui posso decidere come configurare il mio dispositivo:

  1. Trasmetto le informazioni sul dispositivo su cui è in esecuzione il SW a MotorFactorye restituisce il motore corretto, o Motor1o Motor2. In questo caso la logica per decidere è all'interno della Fabbrica.
  2. Configuro il DIC in base al dispositivo su cui è in esecuzione e creo due stabilimenti Motor1Factorye Motor2Factory, dove uno crea Motor1e l'altro Motor2. In questo caso avrei voci di registro diverse IMotornei registri specifici del dispositivo che utilizzano Motor1Factoryo Motor2Factory.

Ora la mia domanda è: quale di questi due metodi è preferibile e perché? Per me, sembra che il primo caso non sia diretto e contorto, poiché sto diffondendo la logica che decide quale tipo di istanza in tutta la base di codice. Mentre nel secondo caso sto moltiplicando efficacemente il numero di fabbriche nel mio codice, poiché avrò bisogno di una fabbrica per (quasi) ogni tipo di calcestruzzo. Diventa ancora più confuso per me, quando si aggiungono fabbriche astratte al mix.

Quindi di nuovo: quando dovrei usare un metodo o l'altro? E ancora più importante: quali sono i buoni indicatori per decidere quale strada da percorrere?


2
In che modo è più semplice? I vantaggi di un approccio più complesso superano i costi della complessità aggiuntiva?
Robert Harvey,

Risposte:


2

Se usi entrambi, proverò qualcosa di semplice:

  • DI / IoC: per ogni configurazione che non verrà modificata in fase di esecuzione.
  • Factory: per la creazione dell'istanza di oggetti in fase di runtime che dipende dai parametri di input del runtime. Le istanze della fabbrica vengono iniettate dal contenitore DI.

1

Le fabbriche astratte vengono utilizzate quando si hanno oggetti correlati attraverso una gerarchia che deve variare insieme. Non lo vedo qui.

Quello che vedo è che ti stai chiedendo se una fabbrica dovrebbe scegliere il motore o se il DIC dovrebbe scegliere una fabbrica che produce un determinato motore.

È difficile scegliere precisamente perché una fabbrica e un DIC fanno cose molto simili. La differenza è che la fabbrica è focalizzata su un problema particolare e il DIC è più generale.

Dipende da questa domanda: hai bisogno di un codice specifico per questo problema che vivrà in fabbrica? O è più generale come leggere i dettagli di configurazione da un file?

Tieni presente che mentre potresti scegliere solo tra Motor1e Motor2oggi, domani potrebbe esserci un Motor3. Favorire il design che sarebbe Motor3facile da aggiungere.


0

Separerei la logica "quale motore usare" in una Fabbrica speciale chiamata Builder (modello) e utilizzerei il contenitore IOC per entrambi i motori come dettaglio di implementazione del costruttore.

Come regola generale:

  • hai bisogno di una factory (o di un builder) se devi creare molti oggetti dinamici della classe / interfaccia. (cioè per ogni auto che produci devi creare un nuovo motore)
  • se hai bisogno solo di un'istanza statica di una classe ioc / di può fare il lavoro per te (cioè hai bisogno solo di un'istanza statica del servizio di pagamento e di un'istanza statica di MotorBuilderService)
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.