Mi sento come se dovessi essere in grado di registrare tutti i miei componenti nel contenitore radice della composizione dell'applicazione indipendentemente dallo stato corrente dell'ambiente, anche nel caso in cui l'ambiente manchi di parti di configurazione richieste per il corretto funzionamento di alcuni dei suoi componenti .
Attualmente, a volte mi imbatto in codice che ad esempio utilizza la funzionalità di Castle Windsor Dependency.OnValue che consente al codice personalizzato dal contenitore di fornire valori del costruttore. Quando un tale codice personalizzato fallisce, l'avvio dell'applicazione non riesce nella fase di composizione, anche prima dell'inizio dell'inizializzazione della classe.
Mi sembra che ogni errore nella fase di composizione che non è di preoccupazione per il quadro IoC (come "la dipendenza circolare rilevata") è in realtà un sintomo di un problema di separazione improprio. Quindi sono tentato di refactoring tali usi di Dependency.OnValue in un componente di configurazione che potrebbe ancora fallire, ma più tardi.
D'altro canto, la regola di fail fail suggerirebbe che è bello che il sistema non inizi a funzionare anche senza che alcuni importanti prerequisiti ambientali siano soddisfatti.
Che cosa suggeriresti?
Modifica: esempio di codice:
public static IWindsorContainer Compose()
{
var container = new WindsorContainer();
container.Register(
// lots of components there
Component
.For<IService>()
.ImplementedBy<DefaultService>()
.DependsOn(Dependency.OnValue<string>(Configuration.GetString("SomeKey")))
// ^ this can fail
// lots of components there
);
return container;
}
Ora, test unitario come questo:
[TestMethod]
public void CompositionDoesntContainCycles()
{
try
{
var container = CompositionRoot.Compose();
}
catch (SomeKindOfCycleExceptionThrownByWindsor)
{
Assert.Fail();
}
}
fallirà perché ho bisogno di simulare la configurazione come Compose () fa due, non una cosa.