Zend Di in ZF 2.0

7,550 views
7,403 views

Published on

This is from a talk at Zendcon 2011. It discusses both Dependency Injection in PHP, with examples from Zend\Di

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,550
On SlideShare
0
From Embeds
0
Number of Embeds
2,301
Actions
Shares
0
Downloads
59
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • Is he talking about the practice or the container?\n
  • \n
  • \n
  • \n
  • \n
  • How many of you use interfaces currently in your code in your orgnaization\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • point in case on next slide:\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Zend Di in ZF 2.0

    1. 1. October 2011ZendDi
    2. 2. Who Am I? •Ralph Schindler (ralphschindler) Software Engineer on the Zend Framework team •At Zend for almost 4 years •Before that TippingPoint/3Com Programming PHP for 13+ years Live in New Orleans, LA. •Lived in Austin, Tx for 5 years My background with Di •I was part of the original roundtable 3yr ago @ zendcon –Fabien + Stephan + Myself2
    3. 3. First Some Background •Background Di Definitions Some generic patterns3
    4. 4. Dependency Injection •Subject matter expert: Martin Fowler not the only one, but has a nice take on it •http://martinfowler.com/articles/ injection.html4
    5. 5. Di vs. DiC •Di is a pattern This is non-negotiable DI is about Inversion Of Control (IoC) –sometimes not an easy concept to grasp for beginner and intermediate developers •DiC is a tool Subject to a developer’s or a group of developers requirements I.E.: no formal definition •as such, lots of frameworks provide this in some way shape or form5
    6. 6. Important Fowler Quote •“Inversion of control is a common feature of frameworks, but its something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isnt to say its a bad thing, just that I think it needs to justify itself over the more straightforward alternative.”6
    7. 7. Di: In a Nutshell •Obligatory:7
    8. 8. Di’s Misguided Argument •Testing everyone quotes this as the argument for dependency injection •correct for silo’d development •if you are the only consumer of your code too much emphasis here8
    9. 9. The Better Di Argument •Makes it easy for developers to swap out implementation •Paddy Brady: ... “it helps ensure source code can be maintained in a highly decoupled state. Which make it easier to subclass the Zend Framework to death, and modify it’s components before use.”9
    10. 10. Di Identified Types •Constructor Favored by PicoContainer derivatives •Setter Favored by Spring Container derivatives10
    11. 11. Di 3rd Injection Type •Interface Injection but first as segue ...11
    12. 12. What is an Interface •A contract that forces subtypes to conform to particular method signatures so that objects can exhibit particular behaviors12
    13. 13. Interfaces •Interface best practices No constructors No static methods •Why? Because interfaces are about “alternate implementations” •PHP allows statics and constructors in interfaces for better or worse13
    14. 14. Interfaces explained •A better way to think about it Interfaces are about contracts in behavior between developers Point in case, search for “friends” in this page: •http://martinfowler.com/articles/injection.html14
    15. 15. Interfaces in practice15
    16. 16. Back To Interface Injection •First and foremost: a communication tool •Form of setter injection (or, injection via method) •The dependency is implied by the interface and the injection point is forced by the interface Always part of the type’s hierarchy •Rely’s on a managing/consuming object/ framework for execution - or a really strict developer16
    17. 17. Interface Injection Example17
    18. 18. Interface Injection Pattern •Not formal / it is semi-de-facto •Interface injection is tricker to understand without context •(Semi) Well known pattern at play the “Aware” interface name18
    19. 19. Interface Injection Downside •At the application layer, it leads to having to write and consume lots of interfaces to get things sorted out19
    20. 20. Interface Injection Downside20
    21. 21. Constructor vs. Setter Injection •Constructor Pro: object in ready state Con: there is a param per dependency •too busy of an object? or just right? Con: dependencies are not polymorphic Pro/Con: dependencies can (not?) be swappable after instantiation Pro: object declares complexity up front Con: can lead to cyclical dependencies21
    22. 22. Constructor vs. Setter Injection •Constructor continued: •Constructors are not subject to Liskov Substitution Principle (Ctor is not part of the type in question) –In other languages ctors are static22
    23. 23. Constructor vs. Setter Injection •Setter Pro: clear injection points for each dependency Con: consumer has to be very honest about injecting all dependencies Con: construct is not up front about required dependencies •hard to distinguish optional vs. required dependencies –is this really such a thing?23
    24. 24. Misconceptions? •(SL) Service Locators !== (DiC) Dependency Injection Containers •But DiC == SL DiC’s can be the foundation of consumed for service location24
    25. 25. Typical Dependency Injection Graph25
    26. 26. Service Locator •It is understood that services to be locator aware •Pros: not all code paths in the consuming object might use all the dependencies •Example: controller •Cons: service locator becomes the dependency26
    27. 27. Service Locator Graph27
    28. 28. •ZendDi28
    29. 29. Why Di For Zend •Considering a DiC is a first world problem for developers •Why did we create this component? You’re afraid of “new”? You asked for it •Having a DI Container that tries to understand your code makes you code better29
    30. 30. Questions Raised •But is it really possible to force developers to write better code? •How do we look at a use case and tell if the DiC is falling short, or the developer is writing bad code? There is a fine line30
    31. 31. DiCs Out There - Not PHP •Java Spring, PicoContainer •.net Spring.Net, StructureMap, Unity, Castle’s Windsor31
    32. 32. ZendDi perspective •we support both: "This issue has led to a lot of debate between the various teams who provide dependency injectors as part of their frameworks. However it seems that most people who build these frameworks have realized that its important to support both mechanisms, even if theres a preference for one of them." •-Martin Fowler32
    33. 33. Developing ZendDi •Development of ZendDi33
    34. 34. Goals •Find a way to produce a DiC that works for PHP developers and all their “tendencies” very hard to identify •Performant - as best as possible we have no persistent memory •The same or less code required than actually just writing the code in the first place34
    35. 35. A Note on DI and Performance •Di is just code, it is a performant as not practicing Di so long as you’re still using the same number of dependencies/objects •DiC is not performance friendly! Front loading workflow, structural needs NOT Hello World friendly!35
    36. 36. ZendDi Parts •Two main components Definition Instance Configuration •Runtime concerns36
    37. 37. ZendDi Definition •Goals Explain what the code looks like, what it expects Identify which classes have dependencies Identify injection points Names for all the moving parts37
    38. 38. ZendDi Definition •Instantiation: Constructor (new keyword) Callback (factory pattern) •Via object factory •Via static factory method38
    39. 39. ZendDi Definition •From a very fundamental level, injection always comes in the two forms Via constructor params Via method injection •We (currently) do not support public property setting39
    40. 40. ZendDi Definition •Naming dependency/configuration entry points Is an object expected? Is there a type hint? •Where does it originate from? Is a scalar expected? Is it optional?40
    41. 41. ZendDi Configuration •Goals Encapsulate runtime data required to wire instances •Could be environment specific (dev. different than production) Be able to identify which objects fulfill a dependency (preferred types)41
    42. 42. Definition & Configuration •A better understanding: Definitions can be shipped with your code, they are independent of how they are used Configuration is what is expected of anyone consuming ZendDi42
    43. 43. Building Definitions •At Runtime (on-demand) Great for development, terrible for production, esp. with annotations turned on •Compiler (Reflection+Scanner) (yesterday’s talk on ZendCode) Compiled into an array; used with ArrayDefinition •By-Hand ClassDefinition BuilderDefinition43
    44. 44. Demo Time •Live Demo Time •Code: https://github.com/ralphschindler/Zend_DI- Examples Uses ZF2 Beta Phars44
    45. 45. Other Containers •Yadif (beberlei) •Pimple (Fabien Potencier) •Symfony Di Container for 5.3 •PicoContainer more than 5 years old45
    46. 46. ZendDi Todo •Further divorce the Service Locator / Dependency Injection Container •Service locators can be defined by callbacks (closures)46
    47. 47. Thanks! •Questions, Concerns? •Thanks!47

    ×