Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zend Di in ZF 2.0

7,832 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
  • Be the first to comment

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

×