Anže Vodovnik gave a talk about dependency injection and why &where it's useful at SLODUG's first season 2011/2012 meeting.

1. Inject Your Dependencies
Inversion of control
Anže Vodovnik
(anze@studiopesec.com)

2. Kdo sem?
• Programski arhitekt
• 10+ let izkušenj (C#, Java...)
• http://www.linkedin.com/in/avodovnik
• @avodovnik
• http://lab.studiopesec.com

3. Kdo je Studio Pešec?
• digital production company
• visoko-performančne, skalabilne (spletne)
aplikacije
• Razvoj po meri
• Svetovanje
• Marketing

4. Job.ru
• 350.000+ unikatnih
obiskovalcev na dan
• ASP.NET & MySQL
• 9 strežnikov

5. CentrSource
• ASP.NET 4 & MSSQL
• Kanada, Madžarska, Slo
venija
• 120.000 unikatnih
obiskovalcev + tiskan
katalog
• Oglaševalska platforma
za direktni marketing

6. Viva.si
• ASP.NET MVC &
MySQL
• Netko
• 6000 dnevno
unikatnih
uporabnikov
• Zdravstvena skupnost

7. MojeDelo.com
• Vodilni zaposlitveni
portal v Sloveniji
• ASP.NET 4.0 in SQL
Azure
• 35.000 dnevno
unikatnih
obiskovalcev
• Windows Azure

8. Agenda
• Odvisnosti v aplikaciji
• Načrtovalski vzorci
• Dependency Injection 101
• Primeri dobrih ogrodji
• Realnost: moja aplikacija in jaz

9. Odvisnosti v aplikaciji
• Kaj je odvisnost?
• Podatkovni nivo & baze
– MySQL, MSSQL, Azure
• Poslovni nivo
• Zunanje storitve & komponente
• .NET framework komponente
– File objekti
– Web objekti (npr. HttpContext, Request...)

10. Odvisnosti: pogled z vrha
Poslovna
UI DAL Baza
logika

11. In?
• Več-nivojska arhitektura je logična ločitev
• Koda je vseeno tesno povezana in odvisna
}
– Stranka 1: MySQL
– Stranka 2: MSSQL
Različne verzije za vse?
– Stranka 3: Azure SQL
– Stranka N: Oracle? („$!“#?!=@„!%“!!“)

12. In? (cnt‘d)
• Težko izoliramo posamezno komponento
– Težje testiranje
– Težje prilagajanje
– Težje vzdrževanje
– Težje spreminjanje / nadgrajevanje

14. Tesna sklopljenost
• Sword in Samurai sta sklopljena
• Ne moremo zamenjati oziroma dodati orožja
brez spreminjanja Samurai razreda
• Vpeljemo prvi nivo abstrakcije: interface

15. REŠITEV 1
PROGRAMMING TO AN INTERFACE

17. Rešitev 1
• Še vedno statična odvisnost med Samurai in
Sword razredom
• Logika (Attack) ni več neposredno odvisna od
implementacije

18. REŠITEV 2
FACTORY PATTERN

20. Rešitev 2
• Še vedno je tesno sklopljen
• Še vedno je statična povezava

21. REŠITEV 3
SERVICE LOCATOR

23. Rešitev 3
+ Samurai ni več statično
odvisen od Sword razreda
+ Večja
razširljivost, testabilnost in
reusability
- Odvisno od sekvence
(Assembler, Samurai)
- Težavno postavljenje (test)
- Lookup problemi?

24. REŠITEV 4
DEPENDENCY INJECTION

25. DEPENDENCY INJECTION
INTERFACE INJECTION

27. DEPENDENCY INJECTION
SETTER INJECTION

29. DEPENDENCY INJECTION
CONSTRUCTOR INJECTION

31. Dependency injection
• Inversion of Control = preveč generičen pojem
• Hollywood Principle
– Don’t call us, we’ll call you
• Martin Fowler predlaga: Dependency Injection

32. Dependency Injection
• Instanciranje na roko?
• Kaj pa povezani razredi?
– new Glock(new Ammo(15, 3));
• Boilerplate koda
• Težko upravljanje (N mnogo lokacij?)
• Upravljanje z življenjskim ciklom

33. Dependency Injection
• Rešitev: IoC Container
• Ninject
• Spring Framework
• Unity
• StructureMap
• Castle Windsor

34. IoC container
• Prevzame dolgočasen del kode

35. IoC container
1. Get<Samurai>()
2. Obstaja mapping?
3. Reflection nad Samurai razredom
1. Najde popoln konstruktor (največ „resolvable“
odvisnosti ali [Inject] atribut)
2. Najde Setterje z [Inject] atributom
4. Instancira razred & odvisnosti
1. Za vsako odvisnost pokliče .Get<Dependency>()

36. IoC container
• V ozadju uporablja
System.Reflection.Emit.DynamicMethod
• Resolva se v delegat, koda je hitrejša
• Lahko uporabite reflection (v nekaterih primerih
je to občutno hitrejše)

37. Dependency Injection 101
• Razrešitev
– Kontekstualna ([Named(„Weak“)]
– Multiple-bindings (IEnumerable<IWeapon>)
• Upravljanje z življenjskim ciklom
– Transient, Singleton, Thread, Request (Http)

38. Resolution: multiple bindings

39. Resolution: named bindings

40. Resolution: več opcij
• Constraints:
– Imena
– Binding Meta-podatki
– Kontekst „tarče“
– predikati

41. Resolution: več opcij

42. Upravljanje z življenjskim ciklom
• Inversion of control? AHA!
• Instanciranje po potrebi
• Dispose po potrebi
• Enostaven nadzor & menjava
– Singleton | per-request | per-thread | lasten
scope
• Privzeto: InTransientScope

43. Upravljanje z življenjskim ciklom
• Transient .InTransientScope()
• Singleton .InSingletonScope()
• Thread .InThreadScope()
• Request .InRequestScope()
• Custom .InScope(Func<object> o)

44. Moduli & nalaganje
• IKernel kernel = new
StandardKernel(new
WeaponsModule(useMeleeWeapons));
• Kernel.Load(„*.dll“);

45. Kako zadevo uporabiti v resničnem življenju?
NINJECT & MVC 3

46. DI & MVC3 = match made in heaven
• MVC3 je predstavil nov interface:
IDependencyResolver
• DependencyResolver.SetResolver(new
UnityDependencyResolver(container));

47. Zakaj?
Poslovna
UI DAL Baza
logika

48. Zakaj?
Controller „Services“ DAL Baza

49. Zakaj?

50. Kako?
• NuGet!
• Ninject.MVC3
– Ninject
– WebActivator

51. Ninject & MVC3
„Assembler“

52. Ninject & MVC3

53. Ninject & MVC3

54. Kdaj uporabiti DI?
• DI = dobra ideja skoraj vedno
• Vprašanje: ročno ali samodejno?

55. Ročno ali samodejno?
Ročni DI Samodejno (IoC container)
Enostavno, skoraj nič učenja Konsistentnost; za večje ekipe, velik +
Nič „črne magije“ – enostavno iskanje Deklerativnost: večina pravil je
klicev (a->b->c) deklerativnih, eno mesto za opis pravil,
eno mesto za spremembo teh pravil
Tudi razvijalci, ki ne razumejo DI lahko Manj tipkanja: ne rabimo se ukvarjat s
sodelujejo na projektu. pisanjem Factory razredov, ipd.
Pomaga pri testiranju! Zelo.

56. Povzetek
• Dependency Injection
• Bolj specifičen termin kot Inversion of Control
• IoC container rešuje mnogo problemov
• Razklopljenost modulov/servisov

57. Viri
• http://www.martinfowler.com/articles/injection.html
• http://lab.studiopesec.com
• http://stackoverflow.com/questions/871405/why-do-i-need-an-ioc-
container-as-opposed-to-straightforward-di-code
• http://ninject.org
• MSDN: Design Patterns – Dependency Injection
http://msdn.microsoft.com/en-us/magazine/cc163739.aspx

58. Vprašanja
• http://www.studiopesec.com
• @studiopesec
• anze@studiopesec.com