Ieri è sorto un argomento in ufficio, sull'utilizzo di un'unità di lavoro contro un DbFactory che produce questi. Per dare un po 'di contesto, abbiamo un'architettura (approssimativa) orientata ai servizi, che segue il pattern IoC con l'iniezione normalmente eseguita al livello più alto (controller), ma utilizza anche una ServiceLocator come soluzione temporanea.
Un lato (A) dell'argomento postula che uno dovrebbe sempre utilizzare un DbFactory nei servizi (di consumo), poiché il sottostante UnitOfWork ha un ambito implicito (breve durata) e l'uso oltre lo scopo previsto possono portare a eccezioni. Dato che non si può sapere come verrà utilizzato il loro servizio in futuro, dovrebbero sempre usare DbFactory quando costruiscono nuovi componenti. Forniscono un esempio in cui un chiamante con una durata indeterminata trattiene un componente transitorio che può quindi fallire in modo casuale. Sostengono quindi che la conoscenza della durata del componente equivale a dettagli di implementazione, che non dovrebbero influire sul modo in cui il chiamante utilizza quel componente.
L'altro lato (B) afferma che l'utilizzo di UnitOfWork nei nuovi componenti va bene, a condizione che siano correttamente contrassegnati come "transitori" all'interno della configurazione DI, in modo simile all'unità di lavoro stesso. Sottolineano che tutte le durate sono definite nel contenitore DI e che questo contenitore deve essere l'unico modo in cui gli oggetti vengono istanziati. Quindi se transitorio significa "vita breve" - e non vorresti mai aggrapparti a un'unità di lavoro "di breve durata", perché rischi di rompersi - non ti manterrai neanche un servizio "di breve durata".
Intuitivamente si preferisce che la durata di vita (unità di lavoro) definita nel livello più basso, mentre l'altra si aspetti che il contenitore DI la gestisca dall'alto. La mia opinione personale è che dovremmo usare gli ambiti di vita forniti prontamente dal contenitore DI, o non usare affatto quel contenitore. Dopotutto, stiamo costruendo un'applicazione web con scope richiesta che definisce il suo significato di "vita transitoria". Mentre la prima parte ha la soluzione "più sicura", ho la minima impressione che stia calpestando i principi KISS / YAGNI / astronauta considerando questi ambienti "ostili" che non ci interessano affatto.
Ora, le domande:
- C'è qualche vantaggio nel sostituire tutte le unità di lavoro con le fabbriche che le producono? Considerando che si può già controllare la durata di una unità ..
- Fabbriche come manager a vita? Perché? Chi gestisce la vita della fabbrica allora? Lo scopo principale di una fabbrica non è lo stesso (incapsulamento, sovraccarico di ctor)?
- Considerando che tutte le vite sono ben definite, dovrebbe essere la responsabilità di un chiamante sapere che un componente è statico (quindi non lo terranno) o è un dettaglio di implementazione che non dovrebbe "filtrare"?
E il più soggettivo:
- Il lato A è semplicemente testardo, non vuole usare il framework DI prontamente disponibile per la gestione a vita, o il lato B manca del perché dovrebbero passare attraverso questi cerchi?