IoC with PHP

IoC with PHP Chris Weldon Dallas TechFest 2011

Before We Begin http://bit.ly/rf1pxRgit://github.com/neraath/ioc-php-talk.git

Your Guide: Chris Weldon• Fightin’ Texas Aggie• .Net and PHP Developer• UNIX and Windows Sysadmin• Senior Consultant at Improving Enterprises• Contact Me: chris@chrisweldon.net

Agile, Microsoft, Open Technologies, UXApplied Training, Coaching, MentoringCertiﬁed ConsultingRural SourcingRecruiting Services

Before We Get to IoC...<?phpclass Authenticator { private $_repository; public function __construct() { $this->_repository = new DataAccessLayer(); } public function authenticate($username, $password) { $hashedPassword = md5($password); $user = $this->_repository->findByUsernameAndPassword( $username, $hashedPassword); return $user === null; }}

What are the problems?

What are the problems?• Strongly coupled to DataAccessLayer

What are the problems?• Strongly coupled to DataAccessLayer Authenticator authenticate() : bool DataAccessLayer ﬁndByUsernameAndPassword : array

What are the problems?• Strongly coupled to DataAccessLayer• Authenticator Very inﬂexible authenticate() : bool DataAccessLayer ﬁndByUsernameAndPassword : array

What are the problems?• Strongly coupled to DataAccessLayer• Authenticator Very inflexible authenticate() : bool• How to configure DataAccessLayer? DataAccessLayer findByUsernameAndPassword : array

What are the problems?• Strongly coupled to DataAccessLayer• Authenticator Very inflexible authenticate() : bool• How to configure DataAccessLayer? • DataAccessLayer Let it read configs? findByUsernameAndPassword : array

What are the problems?• Strongly coupled to DataAccessLayer• Authenticator Very inflexible authenticate() : bool• How to configure DataAccessLayer? • DataAccessLayer Let it read configs? findByUsernameAndPassword : array• How to test the Authenticator?

Let’s solve it• What are our goals? • Decrease coupling • Increase conﬁgurability

<?phpinterface IUserRepository { function findByUsernameAndPassword($username, $password);}class DataAccessLayer implements IUserRepository { private $_configParams; private $_database; public function __construct(array $configParams) { $this->_configParams = $configParams; $this->_database = Zend_Db::factory(Pdo_Mysql, $this->_configParams); } public function findByUsernameAndPassword($username, $password) { $query = SELECT * FROM users WHERE username = ? AND password = ?; $result = $this->_database->fetchAll($query, $username, $password); return $result; }}

Our Updated Authenticator<?phpclass Authenticator { private $_repository; public function __construct(IUserRepository $repository) { $this->_repository = $repository; } public function authenticate($username, $password) { $hashedPassword = md5($password); $user = $this->_repository->findByUsernameAndPassword( $username, $hashedPassword); return $user === null; }}

Time to Consume<?phpclass LoginController { public function login($username, $password) { $configuration = Zend_Registry::get(dbconfig); $dal = new DataAccessLayer($configuration); $authenticator = new Authenticator($dal); if ($authenticator->authenticate($username, $password)) { // Do something to log the user in. } }}

Goal Recap• What were our goals? • Decrease coupling • Increase conﬁgurability

What You Saw Was IoC• Inversion of Control changes direction of responsibility • Someone else responsible for creating and providing my dependencies • Most commonly applied pattern: Dependency Injection • Follows Dependency Inversion Principle from SOLID• Culture War: IoC vs. DI vs. Naming vs. Principles vs. Ideology

Dependency Inversion• “High-level modules should not depend upon low level modules. They should depend upon abstractions.• “Abstractions should not depend upon details. Details should depend upon abstractions.” Robert Martin

Let’s Draw

Let’s Draw Authenticator authenticate() : bool DataAccessLayerﬁndByUsernameAndPassword : array

Let’s Draw Authenticator authenticate() : bool Authenticator authenticate() : bool IUserRepository findByUsernameAndPassword : array DataAccessLayerfindByUsernameAndPassword : array DataAccessLayer findByUsernameAndPassword : array

Beneﬁt: Flexibility<?phpclass WebServiceUserRepository implements IUserRepository { public function findByUsernameAndPassword($username, $password) { // Fetch our user through JSON or SOAP }}class OAuthRepository implements IUserRepository { public function findByUsernameAndPassword($username, $password) { // Connect to your favorite OAuth provider }}

Beneﬁt: Testable<?phpclass WhenAuthenticating extends PHPUnit_Framework_TestCase { public function testGivenInvalidUsernameAndPasswordShouldReturnFalse() { $stub = $this->getMock(IUserRepository); $stub->expects($this->any()) ->method(findByUsernameAndPassword) ->will($this->returnValue(null)); $authenticator = new Authenticator($stub); $this->assertFalse($authenticator->authenticate(user, pass)); }}

Dependency Injection• Now we can inject our dependencies to our consumer classes• Still requires some other class to be tightly coupled to both of those• Need a container that can help abstract the relationship between the interface and implementation

<?phpclass UserRepositoryContainer { /** @return IUserRepository **/ public function getRepository() { $container = new DataAccessLayer(array( dsn => mysql://localhost/database, username => user, password => pass )); return $container; }}class LoginController { public function login($username, $password) { $container = new UserRepositoryContainer(); $repository = $container->getRepository(); $authenticator = new Authenticator($repository); // ... }}

Container Woes• No uniform interface by which to access services• Still tightly coupled with dependencies• Configurability of the container difficult• How to auto-inject dependency for configured consumer classes?

Symfony Dependency Injection Container• Two Ways to Setup and Use sfServiceContainer • Create subclass • Manual registration via code or conﬁg

sfServiceContainer Subclass<?phpclass UserRepositoryContainer extends sfServiceContainer { protected function getUserRepositoryService() { $container = new DataAccessLayer($this[repository.config]); return $container; }}

Consuming the Container<?phpclass LoginController { public function login($username, $password) { $configuration = Zend_Registry::get(dbconfig); $container = new UserRepositoryContainer(array( repository.config => $configuration )); $repository = $container->userRepository; $authenticator = new Authenticator($repository); if ($authenticator->authenticate($username, $password)) { // Do something to log the user in. } }}

That’s Pretty Nice• Conﬁgurability a lot easier• Uniform interface for accessing services• How does this scale when there are lots of dependencies?• Aren’t we still coupling the container to the implementation at compile time?

The Builder• Provides a uniform way of describing services, without custom containers• For each service description, we have the ﬂexibility to conﬁgure an object: • At instantiation (Constructor Injection) • Post-instantiation (Setter/Method Injection)

How to Describe a Service• Code-based or Conﬁg-based • Code-based allows for run-time changing of injection parameters • Conﬁg-based provides a way to change parameters between environments with no code changes • Not mutually exclusive

Code-Based Description<?php// Imagine this is a bootstrap file.$configuration = Zend_Registry::get(dbconfig);$builder = new sfServiceContainerBuilder();$builder->register(user_repository, DataAccessLayer) ->addArgument($configuration) // OR ->addArgument(%repository.config%) from earlier ->setShared(false);$builder->register(authenticator, Authenticator) ->addArgument(new sfServiceReference(user_repository));Zend_Registry::set(di_container, $builder);

Conﬁg-Based Description<?xml version="1.0" ?><container xmlns="http://symfony-project.org/2.0/container"> <parameters> <parameter key="user_repository.dsn">mysql://localhost/database</parameter> <parameter key="user_repository.username">username</parameter> <parameter key="user_repository.password">password</parameter> </parameters> <services> <service id="user_repository" class="DataAccessLayer" shared="false"> <argument type="collection"> <argument key="dsn">%user_repository.dsn%</argument> <argument key="username">%user_repository.username%</argument> <argument key="password">%user_repository.password%</argument> </argument> </service> <service id="authenticator" class="Authenticator"> <argument type="service" id="user_repository" /> </service> </services></container>

Loading the Conﬁg<?php// Imagine this is a bootstrap file.$builder = new sfServiceContainerBuilder();$loader = new sfServiceContainerLoaderFileXml($builder);$loader->load(/pathTo/services.xml);Zend_Registry::set(di_container, $builder);

Using the Container<?phpclass LoginController { public function login($username, $password) { $container = Zend_Registry::get(di_container); $authenticator = $container->authenticator; if ($authenticator->authenticate($username, $password)) { // Do something to log the user in. } }}

High Level Picture DataAccessLayerﬁndByUsernameAndPassword : array IUserRepositoryﬁndByUsernameAndPassword : array sfServiceContainerBuilder getService : object setService : void hasService : bool Authenticatorauthenticate() : bool IAuthenticatorauthenticate() : bool sfServiceContainerInterface getService : object LoginController setService : void login() : void hasService : bool

When to Use a DI Container

When to Use a DI Container• Not for model objects (e.g. Orders, Documents, etc.)

When to Use a DI Container• Not for model objects (e.g. Orders, Documents, etc.)• Great for resource requirements (e.g. repositories, loggers, etc.)

When to Use a DI Container• Not for model objects (e.g. Orders, Documents, etc.)• Great for resource requirements (e.g. repositories, loggers, etc.)• Really great for plugin-type architecture

When to Use a DI Container• Not for model objects (e.g. Orders, Documents, etc.)• Great for resource requirements (e.g. repositories, loggers, etc.)• Really great for plugin-type architecture• But not necessary to use Dependency Injection!

Other Considerations

Other Considerations• Learning curve

Other Considerations• Learning curve• Tracking dependencies

Other Considerations• Learning curve• Tracking dependencies• Dependency changes

Other Considerations• Learning curve• Tracking dependencies• Dependency changes• Setter/method vs. constructor injection

Service Lifetimes• setShared() allows you to specify context persistence • If shared, acts like a singleton • Useful if construction is expensive or state persistence required

Let’s Code

Thank You! http://bit.ly/rf1pxRgit://github.com/neraath/ioc-php-talk.git

http://speakerrate.com	47
http://coderwall.com	14
http://www.linkedin.com	1

IoC with PHP

by Chris Weldon

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 62

Statistics

IoC with PHP Presentation Transcript