Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History
Under Construction
This proposal is under construction and is not ready for review.

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_DI Component Proposal

Proposed Component Name Zend_DI
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_DI
Proposers My E-mail Address
Revision 0.1 - 21 November 2007: Initial Proposal. (wiki revision: 30)

Table of Contents

1. Overview

Zend_DI is a dependency injector component, similar in concept to PicoContainer, but smaller and easier to use. The architecture of the Zend_DI component is based on the following concepts:

  • Dependency injection is a technique that consists of passing objects via the constructor or setter methods.
  • The Container provides an easy way of re-configuring a package to use custom implementations of components.
  • Responsibility for object management is taken over by whatever container is being used to manage those objects.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will use Reflection.

4. Dependencies on Other Framework Components

  • Zend_Config
  • Zend_Exception
  • Zend_Registry

5. Theory of Operation

Zend_DI minimizes coupling between groups of classes, makes unit testing much simpler, and provides an easy way to re-configure a package to use custom implementations of components. For example:

Once we separate configuration from use, we can easily test the Car with different engines. It's just a matter of re-configuring the package and injecting Zend_Car_Parts_Engine_Gas instead of Zend_Car_Parts_Engine_Fuel.

Zend_DI provides generic factory classes that instantiate instances of classes. These instances are then configured by the container, allowing construction logic to be reused on a broader level. Typically, responsibility for object management is taken over by whatever container is being used to manage those objects.

6. Milestones / Tasks

  • Milestone 1: [DONE] Design interface
  • Milestone 2: [IN PROGRESS] Write proposal
  • Milestone 3: Gather feedback and revise design as necessary
  • Milestone 4: Develop full implementation and unit tests
  • Milestone 5: Documentation
  • Milestone 6: Future enhancements

7. Class Index

  • Zend_DI_Container
  • Zend_DI_Exception
  • Zend_DI_Container_Manager
  • Zend_DI_Container_Exception
  • Zend_DI_Component_Factory
  • Zend_DI_Component_Exception

8. Use Cases

For all of these use cases, I'll use the following classes:

The component handles injections via the constructor or setters methods. In addition, Zend_DI allows the user to map out specifications for components and their dependencies in a configuration file and generate the objects based on that specification. The configuration object can be set using the setConfig() method.

Constructor dependency injection:

UC-01
UC-02
UC-03
UC-04

User can map out specifications for components and their dependencies:

UC-05

Setter dependency injection:

UC-06

Containers:

You can tell Zend_DI what classes to manage by adding them to a container (the order of registration has no significance):

UC-07

Containers can be retrieved using the Zend_DI_Container_Manager::getContainer() method, which returns an instance of the Zend_Registry class.

9. Class Skeletons

  • Zend_DI_Container

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.