Come gestire la dipendenza quando si hanno progetti separati?

Question

Come gestire la dipendenza quando si hanno progetti separati?

#1 da (2 voti)

2

So che c'è tutto questo parlare di avere solo una composizione root che imposta tutte le tue dipendenze e che dovresti sempre preferire un'iniezione del costruttore ad altri tipi, ma a volte non ha alcun senso per me. Ecco il mio pseudo codice:

    public class FakeModel
    {
        private FakeDependency Dependency = ServiceLocator.Get<FakeDependency>();

        public string Name { get; private set; }

        public FakeModel(string name)
        {
            Name = name;
        }

        public void UpdateName(string name)
        {
            Dependency.RandomAction();
            Name = name;
        }
    }

Considerazioni speciali:

FakeModel e FakeDependency siedono in un progetto di libreria di classi che riutilizza i miei molti altri progetti.
Tutti gli altri progetti che utilizzano questa libreria di classi non sanno e non dovrebbero neanche sapere che esiste FakeDependency.
Ci sarà sempre una sola implementazione (+ test) di FakeDependency.
L'unico motivo per sostituire FakeDependcy è eseguire test che testano solo la libreria di classi.

Riscriverebbe questo codice in modo diverso, o avrebbe senso considerando i requisiti?

Modifica

Sembra che ci sia una certa confusione sulla dipendenza, sul localizzatore di servizi e su come usare la libreria di classi. Pensa al modello come all'interfaccia pubblica di questa libreria di classi. Tutto il resto è nascosto da altri progetti, non è documentato e soggetto a modifiche in qualsiasi momento. Non dovresti mai usare altri metodi oltre a quelli definiti dal modello.

Informazioni sul localizzatore di servizio; vive all'interno del progetto della biblioteca di classe. Lo scopo è solo quello di rendere possibile testare la libreria di classi e assolutamente non iniettare nuove dipendenze in questa libreria. Se volessi rendere possibile la sostituzione della dipendenza, avrei ovviamente utilizzato un'iniezione del costruttore come quella public FakeModel(string name, FakeDependency dependency) , ma non è così.

Allora come si usa questa libreria di classi al momento? Proprio così:

public void Test()
{
    var model = new FakeModel("MyName");
    model.UpdateName("NewName");
}

La libreria di classi dovrebbe essere autonoma. Forse usare la parola "dipendenza" è fonte di confusione in quanto non è qualcosa che devi fornire alla libreria di classi.

c# dependency-injection dependencies service-locator

posta Gudradain 04.06.2015 - 16:39

fonte

1 risposta

Leggi altre domande sui tag c# dependency-injection dependencies service-locator

Crypto hash in 'a href'? JS Async:. Posso dimenticare i callback tutti insieme e sostituirli con promesse e / o generatori [duplicati]

score 2 · Accepted Answer

Sì, lo riscriverei.

Modifica: nuovo codice basato sui commenti e domande espanse:

[assembly: InternalsVisibleTo("TestAssembly")]
    public class FakeModel
    {
        private IFakeDependency dependency;
        public string Name { get; private set; }

        public FakeModel(string name)
        {
            Name = name;
            this.dependency = new FakeDependency();
        }
        //use this constructor in tests
        internal FakeModel(string name, IFakeDependency dependency)
        {
            Name = name;
            this.dependency = dependency;
        }
        public void UpdateName(string name)
        {
            dependency.RandomAction();
            Name = name;
        }
    }