axxis napísal:Mam problem s korektnym riesenim dependency injection pri pouziti objektov, ktore existuju pocas celeho zivota aplikacie ale potrebuju pre niektore operacie disposable dependency, viete ako sa tento problem spravne riesi?

Skusim byt trochu presnejsi, pri spusteni aplikacie sa vytvori N objektov, ktore reprezentuju konkretny fyzicky terminal, objekty su definovane menom.
Do aplikacie chodia requesty na jednotlive terminaly, ktorych obsluha vyzaduje vytvaranie disposovatelnych dependency, ktore ziju iba pocas reqestu. Keby terminaly nemali singleton zivot riesil by som to jednoducho ako Resolve pri kazdom requeste , kedze vsak nemozem zavolat new na ziadny objekt nemozem si dependency predat v konstruktore a robit to cez property urcite nechcem.

Vie niekto poradit aky je korektny sposob riesenia tohto problemu?

Application start
List.Add(new Terminal1)
List.Add(new Terminal2)
List.Add(new Terminal3)
--instancie vo vnutri listu nie su nikdy diposovoane, ziju az kym aplikacia neskonci (singleton lifetime)

->prichadzajuci request na Terminal1
    List.Find(Terminal1) --v tomto mieste nemozem robit resolve, pretoze instancia Terminalu zije pocas celeho behu aplikacie, mozem spravit resolve na dependency, ale neviem aky je spravny sposob jej injectovania (property setter? parameter metody?)
    Terminal1.UseMethodWithDisposableDependency()

->prichadzajuci request request na Terminal2
    List.Find(Terminal2)
    Terminal2.MethodThatCallsDependencyClass()

->prichadzajuci request request na Terminal1
    List.Find(Terminal1)
    Terminal1.MethodThatCallsDependencyClass()

.
.
.

harrison314 napísal:
Najskor mala pripomeinka, neviem ako to mas riesene, ani aky je navrh, ale nepride mi rozumne drzat objekty realneho sveta ako dependency v IoC kontainery, osobne by som sa tomu vyhol. Terminal podla mna moze pocas behu aplikacie pribudnut alebo odbudnut.

harrison314 napísal:A moja odpoved, tu je to mozes riesit bud tak, ze budes dipsovatelne objekty odovdzavat parametrom. Alebo do terminalu budes injektovat factory pre konkretne disposovatelne zavislosti (je to standardny postup).

di = factory.Create()
di.DoSomething()
di.Dispose()

...mozem spravit resolve na dependency, ale neviem aky je spravny sposob jej injectovania (property setter? parameter metody?

...a robit to cez property urcite nechcem

axxis napísal:Factory vo vnutri needy class je anti pattern. Needy class by nikdy nemala riadit zivot svojej dependency. Ak niekde volas

axxis napísal:tak sa jedna o nespravne pouzitie DI, bezne referovane ako Control-Freak (v tomto konkretnom pripade by si sa Tvoje trieda stala zavislou na predpoklade, ze objekt je disposable ergo zavislou na implementacii). Teraz ma ale nechap zle, nevravim, ze take nieco nutne znici beh programu, tato tema je skor o tom aby som nasiel akademicky najcistejsie riesenie tohto problemu.

harrison314 napísal: V tomto pripade je tou zavislostou factory nie vytvarany objekt.