IoC with PHP

IoC with PHP
Chris Weldon
Dallas TechFest 2011

Before We Begin

http://bit.ly/rf1pxR

git://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, UX
Applied Training, Coaching, Mentoring
Certiﬁed Consulting
Rural Sourcing
Recruiting Services

Before We Get to IoC...
<?php
class 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?

• Strongly coupled to DataAccessLayer


Authenticator
authenticate() : bool

DataAccessLayer
ﬁndByUsernameAndPassword : array



•
Authenticator
Very inﬂexible authenticate() : bool

DataAccessLayer



•
Authenticator

• How to conﬁgure DataAccessLayer?
DataAccessLayer



•
Authenticator


•
DataAccessLayer
Let it read conﬁgs? ﬁndByUsernameAndPassword : array



•
Authenticator


•
DataAccessLayer
Let it read conﬁgs? ﬁndByUsernameAndPassword : array

• How to test the Authenticator?

Let’s solve it

• What are our goals?

• Decrease coupling

• Increase conﬁgurability

<?php
interface 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
<?php
class 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
<?php
class 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

Authenticator

DataAccessLayer

Let’s Draw
Authenticator

Authenticator

IUserRepository

DataAccessLayer

DataAccessLayer

Beneﬁt: Flexibility
<?php
class WebServiceUserRepository implements IUserRepository {
// Fetch our user through JSON or SOAP
}
}

class OAuthRepository implements IUserRepository {
// Connect to your favorite OAuth provider
}
}

Beneﬁt: Testable
<?php
class 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

<?php
class UserRepositoryContainer {
/** @return IUserRepository **/
public function getRepository() {
$container = new DataAccessLayer(array(
'dsn' => 'mysql://localhost/database',
'username' => 'user',
'password' => 'pass'
));

return $container;
}
}

$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

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

Consuming the Container
<?php

$container = new UserRepositoryContainer(array(
'repository.config' => $configuration
));
$repository = $container->userRepository;

$authenticator = new Authenticator($repository);
}
}
}

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.

$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

<?php
$container = Zend_Registry::get('di_container');
$authenticator = $container->authenticator;
}
}
}

High Level Picture
DataAccessLayer

IUserRepository
sfServiceContainerBuilder
getService : object
setService : void
hasService : bool
Authenticator

IAuthenticator

sfServiceContainerInterface
getService : object
LoginController setService : void
login() : void hasService : bool

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




• Really great for plugin-type architecture

• But not necessary to use Dependency Injection!

Other Considerations

• Learning curve


• Learning curve

• Tracking dependencies


• Learning curve


• Dependency changes


• Learning curve


• 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

Thank You!

http://bit.ly/rf1pxR

git://github.com/neraath/ioc-php-talk.git

IoC with PHP

More Related Content

What's hot

Viewers also liked

Similar to IoC with PHP

More from Chris Weldon

Recently uploaded

IoC with PHP

Editor's Notes