SlideShare a Scribd company logo
Dependency
Injection:
išmoktos pamokos
Gediminas Geigalas
UAB Baltic Amadeus
gedgei.wordpress
.com
ba.lt
Turinys
• Problemos
• Sprendimai
• Patarimai
• Rekomenduojama
medžiaga
Sąvokos
•Dependency Injection (DI) -
priklausomybės perdavimas priklausančiam
objektu
•IoC konteineris; konteineris – įrankis
objektų ir jų priklausomybių medžiams kurti
•Composition Root (CR) – vieta, kurioje
sukuriamas objektų ir jų priklausomybių
medis, pvz.:
•var instance = container.Resolve<T>()
Programavimas be DI
Spaudžiam F5
#1: DI yra naudingas
•Viešos priklausomybės
•Lengvesnis perpanaudojimas
•Lengvesnis testavimas
•Lankstesnis gyvavimo trukmės
valdymas
#2: DI galimas ne visur
•Reikalaujama konstruktorių be parametrų
•Nepateikiami plėtimo taškai
•Pavyzdžiai:
•ASP.NET WebForms Page
•RoleProvider
•Windows Workflow Foundation
...bet norim jį naudoti
•Ką daryti, jeigu technologija nepalaiko
DI?
•Facade pattern
•Service locator *
#3: Konstruktoriai
tampa dideli
•Dažniausiai naudojamas constructor
injection
•Priklausomybių skaičius tampa didelis
•Sudėtingesnis palaikymas
Neprivalomos
priklausomybės
•Log‘inimas ir kiti cross-cutting concern
•Keičiam į property injection
•Local default
•Null Object pattern
Facade Services
•Single Responsibility Principo taikymas
•Grupuoja kelias priklausomybes į vieną
#4: Nenaudoti DI
esybėse
•DI naudojimas esybių klasėse
nerekomenduojamas
•Naudoti „servisinėse“ klasėse
•Jeigu esybei reikalinga service klasė, ji
gali būti perduodama metodo
parametrais
#5: Primityvai taip pat
priklausomybės
•Priklausomybė nebūtinai turi būti
sudėtingas objektas
•Primityvai tinkami visiems DI būdams
Konfigūracijos
parametrai
•Nekviesti [Web]ConfigurationManager
klasių tiesiai
•Priimti parametrus per konstruktorių arba
property
•Kūrimo/registracijos metu nuskaitomos ir
panaudojamos konfigūracijos reikšmės
* CR konfigūracijos
demo
#6: Ne viską galima
sukurti iš anksto
•DI atskiria objektų kūrimą nuo jų
panaudojimo
•Ką daryti, jeigu objekto sukūrimas yra
sudėtingas ir neturėtų būti atliekamas
viso medžio kūrimo metu?
•Factory pattern
•Func<T>
•Lazy<T>
•Nepamirškite sunaikinti
sukurto objekto!
#7: Nevisada reikalinga
abstrakcija
•Dažnai naudojant DI įvedamos
abstrakcijos
•Ar jos tikrai reikalingos?
•Abstrakcijos prideda sudėtingumo
•Automatiniam testavimui nebūtinos
DI != DIP
•Dependency Inversion Principas:
• High level modules should not depend on low
level modules – both should depend upon
abstractions
• Abstractions should not depend on the details.
Details should depend upon abstractions.
Reused Abstraction
Principle
•Neįvedinėkite abstrakcijos, jeigu yra tik
viena jos realizacija
•Negalioja skirstant į sluoksnius
#8: Kartais prireikia
bendros registracijos
•Ką daryti, jeigu turim bendrą
priklausomybių registraciją kelioms
aplikacijoms?
Bendra registracija
•Negalima talpinti registracijos kartu su
priklausomybėmis tame pačiame projekte
•Trys būdai:
•Kopijuoti kiekvienoje
aplikacijoje
•Add as link
•Saugoti bendrame aplikacijų
lygio projekte
Composition Root
•Composition Root (CR) – centrinė vieta,
kurioje sukuriamas objektų medis
•Gali būti tik aplikacijose, neturi būti
bibliotekose
•Tipinės vietos .NET programose:
•Console app – Main metodas
•ASP.NET MVC – IControllerFactory
•WCF – IInstanceProvider,
ServiceHostFactory
•Kiek CR gali būti aplikacijoje?
#9: Composition Root
gali būti keli
•Vienoje aplikacijoje yra keli įėjimo taškai
(pvz.: ASP.NET + WCF)
•Tai tarsi kelios aplikacijos vienoje
•Skirtingos priklausomybės skirtinguose
kontekstuose
•Skirtingos gyvavimo trukmės skirtinguose
kontekstuose
#10: Konteineris
reikalingas ne visada
•DI nėra priklausomas nuo įrankių
•Nereikalingas, jei:
•Priklausomybių medis nedidelis
•Rašoma biblioteka ar framework
Kada naudoti konteinerį?
• © Mark Seeman:
http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/
Varguolio DI
•Rankomis konstruojamas priklausomybių
medis turi privalumų:
• Paprasta ir aišku
• Strong typing
• Papildomas tipų tikrinimas kompiliavimo metu
• Circular dependency aptikimas
#11: IoC konteineris
reikalingas, kai..
•Dideli priklausomybių medžiai
•Aspect Oriented Programming
•Late binding
•Lankstus gyvavimo trukmės
konfigūravimas
IoC konteinerio
panaudojimas
•Turėtų būti naudojamas tik CR:
•IoC konteinerį lengva pakeisti kitu
•IoC konteinerio nereikia abstrahuoti
•Nenaudokite atributų DI atlikti
•Nuorodos į konteinerį turėti būti tik
aukščiausiame lygmenyje (aplikacijoje)
DI vs Service Location
•Jei naudoji IoC konteinerį, nereiškia, kad
naudoji DI
•Service Locator
•CommonServiceLocator
•Anti-pattern
•Grąžina paslėptų priklausomybių
problemą
#12: Release yra LABAI
svarbu
•Register Resolve Release šablonas
•LABAI svarbi dalis:
•Tvarkingai uždaromi WCF proxy
•Atlaisvinami IDisposable objektų
resursai
•Pasirinkite IoC konteinerį, kuris palaiko
automatinį objektų medžio naikinimą
(Unity to nesugeba)
Ne visi objektai yra
sekami
•Ką daryti su IoC konteinerio nesekamais
IDisposable ir pnš. objektais?
•Konteineris neseka
objektų, kurių jis nesukūrė
•Objektai turi būti naikinami
tame kontekste, kuriame
buvo sukurti
Rekomenduojama
medžiaga
•Dependency Injection in .NET, Mark Seeman
•http://blog.ploeh.dk/ - Mark Seeman blog‘as
•http://misko.hevery.com/ - straipsniai apie
testuojamą dizainą ir DI
•Agile Principles, Patterns, and Practices [in
C#], Robert Martin
Klausimai
?
Dependency Injection: išmoktos pamokos

More Related Content

More from .NET Crowd

Clean architecture
Clean architectureClean architecture
Clean architecture
.NET Crowd
 
Quantum Computing With the Q# Language
Quantum Computing With the Q# LanguageQuantum Computing With the Q# Language
Quantum Computing With the Q# Language
.NET Crowd
 
Fast IDentity Online New wave of open authentication standards
Fast IDentity Online New wave of open authentication standardsFast IDentity Online New wave of open authentication standards
Fast IDentity Online New wave of open authentication standards
.NET Crowd
 
Multi-threading your way out
Multi-threading your way outMulti-threading your way out
Multi-threading your way out
.NET Crowd
 
Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)
Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)
Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)
.NET Crowd
 
Typescript language
Typescript languageTypescript language
Typescript language
.NET Crowd
 
Raimondas tijunaitis tackle_big_ball_of_mud_super_mario_style
Raimondas tijunaitis tackle_big_ball_of_mud_super_mario_styleRaimondas tijunaitis tackle_big_ball_of_mud_super_mario_style
Raimondas tijunaitis tackle_big_ball_of_mud_super_mario_style
.NET Crowd
 
Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...
Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...
Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...
.NET Crowd
 
Rokas Balevičius "Logstash - system heartbeat implementation"
Rokas Balevičius "Logstash - system heartbeat implementation"Rokas Balevičius "Logstash - system heartbeat implementation"
Rokas Balevičius "Logstash - system heartbeat implementation"
.NET Crowd
 
Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"
.NET Crowd
 
Donatas Mačiūnas "Git - pažabokim istoriją"
Donatas Mačiūnas "Git - pažabokim istoriją"Donatas Mačiūnas "Git - pažabokim istoriją"
Donatas Mačiūnas "Git - pažabokim istoriją"
.NET Crowd
 

More from .NET Crowd (11)

Clean architecture
Clean architectureClean architecture
Clean architecture
 
Quantum Computing With the Q# Language
Quantum Computing With the Q# LanguageQuantum Computing With the Q# Language
Quantum Computing With the Q# Language
 
Fast IDentity Online New wave of open authentication standards
Fast IDentity Online New wave of open authentication standardsFast IDentity Online New wave of open authentication standards
Fast IDentity Online New wave of open authentication standards
 
Multi-threading your way out
Multi-threading your way outMulti-threading your way out
Multi-threading your way out
 
Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)
Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)
Visual Studio Team Services Extensions by Taavi Kõosaar (@melborp)
 
Typescript language
Typescript languageTypescript language
Typescript language
 
Raimondas tijunaitis tackle_big_ball_of_mud_super_mario_style
Raimondas tijunaitis tackle_big_ball_of_mud_super_mario_styleRaimondas tijunaitis tackle_big_ball_of_mud_super_mario_style
Raimondas tijunaitis tackle_big_ball_of_mud_super_mario_style
 
Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...
Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...
Tomas Urbonaitis "Introduction to asynchronous persistent messaging with NSer...
 
Rokas Balevičius "Logstash - system heartbeat implementation"
Rokas Balevičius "Logstash - system heartbeat implementation"Rokas Balevičius "Logstash - system heartbeat implementation"
Rokas Balevičius "Logstash - system heartbeat implementation"
 
Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"Andrej Slivko "CQRS praktikoje"
Andrej Slivko "CQRS praktikoje"
 
Donatas Mačiūnas "Git - pažabokim istoriją"
Donatas Mačiūnas "Git - pažabokim istoriją"Donatas Mačiūnas "Git - pažabokim istoriją"
Donatas Mačiūnas "Git - pažabokim istoriją"
 

Dependency Injection: išmoktos pamokos

  • 1. Dependency Injection: išmoktos pamokos Gediminas Geigalas UAB Baltic Amadeus gedgei.wordpress .com ba.lt
  • 2. Turinys • Problemos • Sprendimai • Patarimai • Rekomenduojama medžiaga
  • 3. Sąvokos •Dependency Injection (DI) - priklausomybės perdavimas priklausančiam objektu •IoC konteineris; konteineris – įrankis objektų ir jų priklausomybių medžiams kurti •Composition Root (CR) – vieta, kurioje sukuriamas objektų ir jų priklausomybių medis, pvz.: •var instance = container.Resolve<T>()
  • 5. #1: DI yra naudingas •Viešos priklausomybės •Lengvesnis perpanaudojimas •Lengvesnis testavimas •Lankstesnis gyvavimo trukmės valdymas
  • 6. #2: DI galimas ne visur •Reikalaujama konstruktorių be parametrų •Nepateikiami plėtimo taškai •Pavyzdžiai: •ASP.NET WebForms Page •RoleProvider •Windows Workflow Foundation
  • 7. ...bet norim jį naudoti •Ką daryti, jeigu technologija nepalaiko DI? •Facade pattern •Service locator *
  • 8. #3: Konstruktoriai tampa dideli •Dažniausiai naudojamas constructor injection •Priklausomybių skaičius tampa didelis •Sudėtingesnis palaikymas
  • 9. Neprivalomos priklausomybės •Log‘inimas ir kiti cross-cutting concern •Keičiam į property injection •Local default •Null Object pattern
  • 10. Facade Services •Single Responsibility Principo taikymas •Grupuoja kelias priklausomybes į vieną
  • 11. #4: Nenaudoti DI esybėse •DI naudojimas esybių klasėse nerekomenduojamas •Naudoti „servisinėse“ klasėse •Jeigu esybei reikalinga service klasė, ji gali būti perduodama metodo parametrais
  • 12. #5: Primityvai taip pat priklausomybės •Priklausomybė nebūtinai turi būti sudėtingas objektas •Primityvai tinkami visiems DI būdams
  • 13. Konfigūracijos parametrai •Nekviesti [Web]ConfigurationManager klasių tiesiai •Priimti parametrus per konstruktorių arba property •Kūrimo/registracijos metu nuskaitomos ir panaudojamos konfigūracijos reikšmės * CR konfigūracijos demo
  • 14. #6: Ne viską galima sukurti iš anksto •DI atskiria objektų kūrimą nuo jų panaudojimo •Ką daryti, jeigu objekto sukūrimas yra sudėtingas ir neturėtų būti atliekamas viso medžio kūrimo metu? •Factory pattern •Func<T> •Lazy<T> •Nepamirškite sunaikinti sukurto objekto!
  • 15. #7: Nevisada reikalinga abstrakcija •Dažnai naudojant DI įvedamos abstrakcijos •Ar jos tikrai reikalingos? •Abstrakcijos prideda sudėtingumo •Automatiniam testavimui nebūtinos
  • 16. DI != DIP •Dependency Inversion Principas: • High level modules should not depend on low level modules – both should depend upon abstractions • Abstractions should not depend on the details. Details should depend upon abstractions.
  • 17. Reused Abstraction Principle •Neįvedinėkite abstrakcijos, jeigu yra tik viena jos realizacija •Negalioja skirstant į sluoksnius
  • 18. #8: Kartais prireikia bendros registracijos •Ką daryti, jeigu turim bendrą priklausomybių registraciją kelioms aplikacijoms?
  • 19. Bendra registracija •Negalima talpinti registracijos kartu su priklausomybėmis tame pačiame projekte •Trys būdai: •Kopijuoti kiekvienoje aplikacijoje •Add as link •Saugoti bendrame aplikacijų lygio projekte
  • 20. Composition Root •Composition Root (CR) – centrinė vieta, kurioje sukuriamas objektų medis •Gali būti tik aplikacijose, neturi būti bibliotekose •Tipinės vietos .NET programose: •Console app – Main metodas •ASP.NET MVC – IControllerFactory •WCF – IInstanceProvider, ServiceHostFactory •Kiek CR gali būti aplikacijoje?
  • 21. #9: Composition Root gali būti keli •Vienoje aplikacijoje yra keli įėjimo taškai (pvz.: ASP.NET + WCF) •Tai tarsi kelios aplikacijos vienoje •Skirtingos priklausomybės skirtinguose kontekstuose •Skirtingos gyvavimo trukmės skirtinguose kontekstuose
  • 22. #10: Konteineris reikalingas ne visada •DI nėra priklausomas nuo įrankių •Nereikalingas, jei: •Priklausomybių medis nedidelis •Rašoma biblioteka ar framework
  • 23. Kada naudoti konteinerį? • © Mark Seeman: http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/
  • 24. Varguolio DI •Rankomis konstruojamas priklausomybių medis turi privalumų: • Paprasta ir aišku • Strong typing • Papildomas tipų tikrinimas kompiliavimo metu • Circular dependency aptikimas
  • 25. #11: IoC konteineris reikalingas, kai.. •Dideli priklausomybių medžiai •Aspect Oriented Programming •Late binding •Lankstus gyvavimo trukmės konfigūravimas
  • 26. IoC konteinerio panaudojimas •Turėtų būti naudojamas tik CR: •IoC konteinerį lengva pakeisti kitu •IoC konteinerio nereikia abstrahuoti •Nenaudokite atributų DI atlikti •Nuorodos į konteinerį turėti būti tik aukščiausiame lygmenyje (aplikacijoje)
  • 27. DI vs Service Location •Jei naudoji IoC konteinerį, nereiškia, kad naudoji DI •Service Locator •CommonServiceLocator •Anti-pattern •Grąžina paslėptų priklausomybių problemą
  • 28. #12: Release yra LABAI svarbu •Register Resolve Release šablonas •LABAI svarbi dalis: •Tvarkingai uždaromi WCF proxy •Atlaisvinami IDisposable objektų resursai •Pasirinkite IoC konteinerį, kuris palaiko automatinį objektų medžio naikinimą (Unity to nesugeba)
  • 29. Ne visi objektai yra sekami •Ką daryti su IoC konteinerio nesekamais IDisposable ir pnš. objektais? •Konteineris neseka objektų, kurių jis nesukūrė •Objektai turi būti naikinami tame kontekste, kuriame buvo sukurti
  • 30. Rekomenduojama medžiaga •Dependency Injection in .NET, Mark Seeman •http://blog.ploeh.dk/ - Mark Seeman blog‘as •http://misko.hevery.com/ - straipsniai apie testuojamą dizainą ir DI •Agile Principles, Patterns, and Practices [in C#], Robert Martin