Successfully reported this slideshow.

Dependency Injection: išmoktos pamokos

0

Share

Upcoming SlideShare
Clean architecture
Clean architecture
Loading in …3
×
1 of 32
1 of 32

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Dependency Injection: išmoktos pamokos

  1. 1. Dependency Injection: išmoktos pamokos Gediminas Geigalas UAB Baltic Amadeus gedgei.wordpress .com ba.lt
  2. 2. Turinys • Problemos • Sprendimai • Patarimai • Rekomenduojama medžiaga
  3. 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>()
  4. 4. Programavimas be DI Spaudžiam F5
  5. 5. #1: DI yra naudingas •Viešos priklausomybės •Lengvesnis perpanaudojimas •Lengvesnis testavimas •Lankstesnis gyvavimo trukmės valdymas
  6. 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. 7. ...bet norim jį naudoti •Ką daryti, jeigu technologija nepalaiko DI? •Facade pattern •Service locator *
  8. 8. #3: Konstruktoriai tampa dideli •Dažniausiai naudojamas constructor injection •Priklausomybių skaičius tampa didelis •Sudėtingesnis palaikymas
  9. 9. Neprivalomos priklausomybės •Log‘inimas ir kiti cross-cutting concern •Keičiam į property injection •Local default •Null Object pattern
  10. 10. Facade Services •Single Responsibility Principo taikymas •Grupuoja kelias priklausomybes į vieną
  11. 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. 12. #5: Primityvai taip pat priklausomybės •Priklausomybė nebūtinai turi būti sudėtingas objektas •Primityvai tinkami visiems DI būdams
  13. 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. 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. 15. #7: Nevisada reikalinga abstrakcija •Dažnai naudojant DI įvedamos abstrakcijos •Ar jos tikrai reikalingos? •Abstrakcijos prideda sudėtingumo •Automatiniam testavimui nebūtinos
  16. 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. 17. Reused Abstraction Principle •Neįvedinėkite abstrakcijos, jeigu yra tik viena jos realizacija •Negalioja skirstant į sluoksnius
  18. 18. #8: Kartais prireikia bendros registracijos •Ką daryti, jeigu turim bendrą priklausomybių registraciją kelioms aplikacijoms?
  19. 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. 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. 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. 22. #10: Konteineris reikalingas ne visada •DI nėra priklausomas nuo įrankių •Nereikalingas, jei: •Priklausomybių medis nedidelis •Rašoma biblioteka ar framework
  23. 23. Kada naudoti konteinerį? • © Mark Seeman: http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/
  24. 24. Varguolio DI •Rankomis konstruojamas priklausomybių medis turi privalumų: • Paprasta ir aišku • Strong typing • Papildomas tipų tikrinimas kompiliavimo metu • Circular dependency aptikimas
  25. 25. #11: IoC konteineris reikalingas, kai.. •Dideli priklausomybių medžiai •Aspect Oriented Programming •Late binding •Lankstus gyvavimo trukmės konfigūravimas
  26. 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. 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. 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. 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. 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
  31. 31. Klausimai ?

×