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

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.

Benefits of using a DI Container:

• Easy best practice unit testing
• Component reuse
• Centralized configuration
• Clean and declarative architecture
• Maintainability and adaptability

2. References

• Martin Fowler Dependency Injection pattern
• PicoContainer

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

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.

Lets assume we have the following classes:

Constructor dependency injection

The configuration array is typically set up in a different class. For example, each package can have its own configuration file, a PHP class or an XML file. The configuration file holds the components specifications and package dependencies.

Users can map out specifications for components and their dependencies:

Setter dependency injection

Containers

You can tell Zend_DI what classes to manage by adding them to a container (the order of registration has no significance). Containers can be retrieved using the Zend_DI_Container_Manager::getContainer() method, which returns an instance of the Zend_Registry class.

You can register your own container as long as you pass an instance of the Zend_Registry class. New containers can be register using the registerContainer() method.

9. Class Skeletons

• Zend_DI_Container

• Zend_DI_Component_Factory

• Zend_DI_Container_Manager