Esiste un modo in cui un container di unità può passare a un oggetto?Un container di unità può passare un riferimento di sé come parametro costruttore?
cioè .:
public class Something {
public Something(IUnityContainer container) {
...
}
}
La risposta è sì.
Questo deve essere passato automaticamente quando si utilizzano i metodi Resolve.
Ad esempio:
IUnityContainer container = new UnityContainer();
var something = container.Resolve<Something>();
Inoltre, questa è la stessa tecnica che Prism (su CodePlex) utilizza, se si vuole guardare in quella.
Aggiornamento Aggiunto di prova:
[TestClass]
public class Spike
{
[TestMethod]
public void unityTest()
{
var container = new UnityContainer();
var something= container.Resolve<Something>();
Assert.AreSame(container, something.Container);
// This passes. Success.
}
}
public class Something
{
public Something(IUnityContainer container)
{
Container = container;
}
public IUnityContainer Container { get; set; }
}
Come accennato bendewey si può passare, in quanto è un oggetto, come qualsiasi altro oggetto, ma, perché passarlo?
Ne hai solo uno, perché non avere una proprietà statica accessibile a qualsiasi classe?
La preoccupazione che ho con questo approccio è che può causare dipendenze non necessarie sul progetto che contiene una classe statica. Nella mia esperienza, l'iniezione del contenitore aiuta anche i test. – bendewey
Per lo stesso motivo per cui gli accessorici statici non vengono utilizzati per altre dipendenze: complica la testabilità. –
Invece di avere una logica nel framework di test dell'unità per ottenere il contenitore, sarebbe meglio, IMO, avere una classe separata per gestire il contenitore, in modo da poter testare quella classe. Ora sai che funziona correttamente, quindi il tuo test unitario non sta usando qualcosa non testato. Cerco di avere pochissime funzioni di utilità in un test unitario, in quanto anche quelle dovrebbero essere testate. –
La prima risposta è una sorta di cosa stavo pensando. Grazie.
Prima di Unità, abbiamo costruito il nostro proprio contenitore CIO, e noi abbiamo una sintassi qualcosa di simile ...
<constructor>
<param name="factory" value="[{factory}]"/>
</constructor>
Il [{} fabbrica] fa sì che passasse per sé come parametro.
Come impostazione come statico: non mi piace utilizzare tale approccio perché ogni oggetto diventa dipendente dalla singola proprietà (ovviamente). È meno riutilizzabile e meno verificabile, specialmente se la statica è di sola lettura (quale dovrebbe essere). Una volta che la static è impostata, non puoi (o non dovresti essere in grado di) pasticciarla, il che limita gli scenari di test che puoi creare.
Se non altro, quindi gli oggetti dovrebbero almeno essere in grado di accettare un contenitore come parametro. Se non è lì, allora potrebbe ricadere in una statica.
Abbiamo iniziato a utilizzare la singola istanza e abbiamo finito per cambiare tutto. Secondo me, gli oggetti dovrebbero essere più flessibili di così. Se il consumatore degli oggetti vuole avere una singola istanza che passa ai suoi oggetti, questo dipende dal consumatore. Ma l'oggetto stesso non dovrebbe richiederlo. Con la sintassi mostrata sopra, è davvero facile passare il contenitore attraverso il grafico.
Grazie per le informazioni.
Jay
Scusate ... nuovo ragazzo. Vedo che questo dovrebbe essere stato un commento, non una risposta.
Questo potrebbe anche essere stato formulato come aggiornamento alla tua domanda originale. Inoltre, tieni presente che il voto può prendere il commento di "prima risposta" dal contesto. – bendewey
Non è necessario registrare il contenitore con se stesso. Per impostazione predefinita, risolverà la dipendenza di IUnityContainer da solo. –
Non ho avuto il tempo di eseguire il picco la scorsa notte grazie per averlo sottolineato. Ho aggiunto il test che ho usato. – bendewey