SitePoint Sponsor |
|
User Tag List
Results 51 to 75 of 116
Thread: Dependency Injection in PHP4
-
Sep 10, 2005, 06:47 #51
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Oh, you are correct. IIRC, the false constant should require a temp var though.
-
Sep 10, 2005, 06:51 #52
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
Might be an idea to add a trigger_error there, I've added it in the attached. Could do with converting the test file into a SimpleTest and to make sure that all the references are good.
DouglasHello World
-
Sep 10, 2005, 07:01 #53
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Thanks for the zip. I have been wanting to play, but I am sitting at home with a cold and screaming kids all around me. Not exactly the best conditions for sifting through a thread and pulling out code
-
Sep 10, 2005, 11:17 #54
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Originally Posted by DougBTX
I also polished the test script a little bit, so usage is a little clearer for newcomers.
Originally Posted by sweatje
One thing I forgot to mention. When I was looking at the Ruby way of doing things, I automatically decided to create the lambda function with a reference to the injector, probably just imitating the original example using closures.
PHP Code:$registry[$serviceName]['constructor'] = create_function('$di', $block);
PHP Code:DI::register(
'store',
'return new MyStore($di->("gateway"));');
PHP Code:DI::register(
'store',
'return new MyStore(DI::get("gateway"));');
Originally Posted by DougBTX
If kyber / arborint et all think they can use this style of a dependency injector in their application controller design, I would love to help them fit it in. At a personal level, this is likely to become the core of all of my newly developed applications, the advantages of elevating dependency wiring to the top level are just too good to pass.
Maybe the next step is to create the proper unit tests, and I would like to write a small document explaining the advantages of DI and the use of the injector.
Originally Posted by DougBTX
Latest version attached.Garcia
-
Sep 10, 2005, 11:35 #55
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'm in the background following this thread. It appears that Dependency Injection has some interesting aspects to it I suppose but I'm still pondering on all this myself.
Waiting to see where it goes
-
Sep 10, 2005, 13:57 #56
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by ghurtado
This thread, and the others, have given me lot's of ideas for Phemto as you can imagine. The eval/block based approach is certainly a drastic solution. I could never quite bring mysef to do it (having had bad experiences adding PartialMock hooks, now removed). Maybe I am becoming a conservative old fuddy, duddy, but won't syntax and other errors (all those extra semicolons) really confuse the hell out of people? Espcially if it all goes wrong inside a framework which you don't know a lot about? Not so bad in PHP5 with exceptions, but I just get a little uneasy.
Originally Posted by ghurtado
Or I could just be an old fuddy, duddy...
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 10, 2005, 14:10 #57
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
The consequences are both subtle and far reaching.
A while back, sometime last year I read over the 1, 2 and 5 minute tutorials on the PicoContainer site and at the time didn't really understand it all, nor did I understand the need for it.
Been back there today, and after reading them again (and catching up on the Service Locator) I understand a bit more, thanks partly to the discussions on this forum which has sparkled my interest again.
So, to Marcus, Kyber, et al thanks for your interesting thoughts on this, and maybe I'll see about putting something together soon, so I know for myself if I can implement this as well
-
Sep 10, 2005, 14:52 #58
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by ghurtado
PHP Code:$di =& DI::getInstance();
$di->register(
'order',
'return new MyOrder();');
Originally Posted by ghurtado
Latest version attached. (I think it helps a lot that the discussion on how to write something is done in code, not just words, and that every time something changes, the new code is posted. Keeps everything transparent, and it is possibly easier to associate comments in a post with the code at that state than directly via CVS.)
DouglasHello World
-
Sep 10, 2005, 14:55 #59
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Howdy all,
Wow... Marcus is right, the general DI concept is getting a lot of discussion in the PHP world as of late.
The discussion on the Solar list that Marcus mentioned got moved off-list with Jason and Marcus (two guys I both knew were interested in DI) being CC'd. Jason suggested that the comments could be contributed here, and I believe he's right.
I'll save you the whole thread and bring it in on the ending part:
Originally Posted by myself in an email thread
One thing I am looking to do is remove all of the register() calls that Pico and Phemto have and keep from having to fully load every object I might want to use. The latter of these removes the need for reflection provided in PHP 5 and I had already thought would lend itself to being backported to PHP 4.
Marcus, I do have an issue with the code you're using - it requires your injector to become a Singleton. Unless a Registry is implemented, how would I go about having two seperate injectors in the same execution? I think by becoming a Singleton, you're overstepping what the injector needs to do. Worrying about how objects are made aware of it should happen at the implementation level.
-
Sep 10, 2005, 15:14 #60
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
PHP Code:$di =& DI::getInstance('First Instance');
$di->register(
'store',
'return new MyStore($di->get("gateway"));');
$c =& DI::getInstance('Second Instance');
$c->register(
'store',
'return new MyOtherStore($di->get("gateway"));');
Regards,
DouglasHello World
-
Sep 10, 2005, 15:20 #61
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Originally Posted by lastcraft
So in short, I agree that there are shortcomings, it is just that I believe that for a developer who is advanced enough to know what Dependency Injection is in the first place, these are more than likely minimal issues, and the tradeoff between flexibility and safety might be a worthy one. Or maybe you have to be truly "dynamically typed" at heart to feel totally comfortable with this design.
Originally Posted by lastcraft
Using eval() and create_function() is like pushing the queen early. Chessmasters can do it because they know what they're doing. Beginners and intermediates, however, are quick to attack without recognizing the long term danger.
So too, programmers who have *actually completed a curriculum in computer science* and are aware of their algorithmic options and computational complexities, can find incredible possibilities for eval() and create_function() and should find no fear in calling those functions.
Thanks a lot for your input, it really means a lot.Garcia
-
Sep 10, 2005, 16:04 #62
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
PHP Code:DI::register(
'store',
'return new MyStore(DI::get("gateway"));');
Originally Posted by DougBTX
Shameful, I know, but this is the excuse I was waiting for to jump in, I think I am becoming test infected too.
I noticed you changed _getInstance to getInstance, which is funny, because I myself went back and forth a few times with that trying to decide whether it was a "private" method or not. I like DI::getInstance better anyway, since we want to allow traditional singleton usage.
Originally Posted by DougBTX
Travis,
I have a question about your implementation
PHP Code:$dm = new DependencyManager();
$dm->registerPackage(new Package1());
$dm->registerPackage(new Package2());
Thanks to everyone for their input.Garcia
-
Sep 10, 2005, 17:04 #63
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Originally Posted by ghurtado
Here's a PNG of the diagram I was working off of, I think it will help clarify:
With this setup, InterfaceContainer contains knowledge of X number of implementations. If hasComponent('Bird') returns true, then getComponent('Bird') will return the object InterfaceContainer knows about that implements Bird. Though InterfaceContainer only requires one interface to attempt to do a match, my plan is to allow hasComponent('Bird'[, 'Blue']) which would only return objects implementing Bird that and Blue so you are given finer grain control.
As far as the InterfaceProxy object, it will only require that it knows how to load the Interface that it represents. My initial thought, and the reason that I included several private methods in the UML diagram, is that it will know how that particular Interface should behave. This can currently be done with Pico or Phemto, but I think each one of the InterfaceProxies should know this. Though I haven't studied them intently, I believe what I'm implementing here is similar to Pico's Adapter interfaces.
This brings me back full circle to how I'll acheive lazy loading. The various InterfaceContainer objects will already know via configuration (hard coded, from storage, or some other implementation-dependent means) what it has access to, where it's located, what it implements, what it requires, etc. Until the call $dm->loadObject() is made, the only thing that will be loaded is the meta data for the object. Since I don't plan on using Reflections (though there's nothing stopping someone from implementing an InterfaceContainer that does so), the class won't need to be loaded until it is requested.
One thing that might need clarification...
Originally Posted by Travis S
PHP Code:$iniContainer = new IniInterfaceContainer('/path/to/config.ini');
$xmlContainer = new XmlInterfaceContainer('/path/to/config.xml');
$arrayContainer = new ArrayInterfaceContainer('/path/to/config.array.php');
$domContainer = new DomInterfaceContainer($domObject);
//etc., etc., etc.
PHP Code:$pico = new PicoLikeInterfaceContainer();
$pico->registerComponentInstance('BlueBird');
$dm = new DependencyManager();
$dm->registerPackage($pico);
$component = $dm->loadObject('Bird', 'Blue');
$component instanceof BlueBird;
-
Sep 10, 2005, 17:33 #64
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Travis S
There has been enough interest in it since, that I may place it on a more formal footing once the current SimpleTest release cycle is done.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 10, 2005, 21:43 #65
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I always thought the Handle mechanism from WACT could evolve into a DI container. Inspired by this thread, an experiment your consideration:
PHP Code:<?php
require 'framework/util/inject.inc.php';
class DatabaseConfiguration {
var $driver = 'yowza!';
}
class DatabaseConnection {
var $config;
function DatabaseConnection(&$configuration) {
$this->config =& $configuration;
}
function showDriver() {
echo $this->config->driver;
}
}
class EventListener {
function yowza(&$connection) {
$connection->showDriver();
}
}
class EventSource {
var $eventListeners;
var $injectionContainer;
function EventSource(&$injectionContainer) {
$this->eventListeners =& new MulticastNotifier();
$this->eventListeners->setInjectionContainer($injectionContainer);
$this->injectionContainer =& $injectionContainer;
}
function onEvent() {
$connection =& $this->injectionContainer->getInstance('ConnectionAlias');
$this->eventListeners->invokeAll(array(&$connection));
}
function registerEventListener(&$listener) {
$this->eventListeners->addListener($listener);
}
}
$container =& new InjectionContainer();
// register a specific instance
$container->registerSingletonComponent('DatabaseConfiguration', new DatabaseConfiguration());
// register a class to be constructed on demand
$container->registerComponent('GlobalListener', new Handle('EventListener'));
// register a class to be constructed on demand with a construction parameter
// that is also a component
$container->registerComponent('DatabaseConnection',
new Handle('DatabaseConnection', array(new Injection('DatabaseConfiguration'))));
// register an alias for no real reason other than we can
$container->registerComponent('ConnectionAlias', new Injection('DatabaseConnection'));
// A Scary complex example with both constructor and setter injection
$container->registerComponent('EventSource',
new Handle('EventSource',
array(
new Injection('injectionContainer'),
'registerEventListener' => new Callback(
new Injection('GlobalListener'),
'yowza'
)
)
)
);
// We can register ourself
$container->registerComponent('injectionContainer', $container);
$source =& $container->getInstance('EventSource');
$source->onEvent();
?>
PHP Code:Handle('class');
new class();
PHP Code:Handle('class', array('a'));
new class('a');
PHP Code:Handle('class', array('setter' => 'value'));
$obj =& new class();
$obj->setter('value');
PHP Code:$container->registerComponent('DatabaseConnection',
new Handle('DatabaseConnection', array(new Injection('DatabaseConfiguration'))));
PHP Code:$container->registerComponent('injectionContainer', $container);
$container->registerSingletonComponent('DatabaseConfiguration', new DatabaseConfiguration());
PHP Code:$container->registerComponent('ConnectionAlias', new Injection('DatabaseConnection'));
PHP Code:new Callback(new Injection('GlobalListener'), 'yowza')
Last edited by Selkirk; Sep 10, 2005 at 22:53. Reason: Went to bed but decided to get back up and offer more explaination
-
Sep 10, 2005, 21:56 #66
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I finally had some time to catch up with these DI threads. It is fascinating. I am getting the sense that DI in PHP is evolving toward a kind of Service Locator + Lazy Loading + Object Persistence. The nature of how PHP executes scripts and the support (or lack of it) in the language seems to push us that way. DI is really needed in PHP for what are often called "enterprise" apps. And this subject dovetails with the framework treads because DI should be part of the core of the next generation of PHP frameworks.
Christopher
-
Sep 11, 2005, 03:55 #67
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
DouglasHello World
-
Sep 11, 2005, 09:49 #68
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Feel free to prove me wrong, hopefuly with some example codeGarcia
-
Sep 11, 2005, 10:33 #69
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
With a Service Locator, I believe you're correct. Before I proceed though, I'll warn you that my knowledge of a service locator is minimal at best and mostly derived just a basic understanding of the role it is supposed to fill.
This is where the SL and DI patterns seperate. An SL is used by an object, a DI isn't even known to an object.
PHP Code:// Using no locator/injection
class Person {
public function __construct() {
$this->_brain = new SmartBrain();
}
}
// Using Service Locator
class Person {
public function __construct() {
$sl = SL::instance();
$this->_brain = $sl->lookup('Brain');
}
}
// Using Dependency Inection
class Person {
public function __construct(Brain $brain) {
$this->_brain = $brain;
}
}
This is where DI picks up its usefullness. With the first example, you can't test without creating a real Brain - and we all know how expensive an operation it would be to create a smart brain out of thin air.With the second example, you can't test without creating an SL to handle locating the brain. With the third example, however, you can test by directly handing in a MockBrain and not worry about how the DI is going to work later on.
To extend this into a test:
PHP Code:class Person {
public function __construct(Brain $brain) {
$this->_brain = $brain;
}
public function goForAWalk() {
return $this->_brain->consider('walk');
}
public function killSomeone() {
return $this->_brain->consider('kill');
}
}
interface Brain {
/**
* Returns true or false as to whether this is a valid action
*
* @return boolean
*/
public function consider($action);
}
Mock::generate('Brain');
class TestOfPerson extends UnitTestCase
{
public function testWillWalk() {
$brain = new MockBrain($this);
$brain->setReturnValue('considerAction', true);
$person = new Person($brain);
$this->assertTrue($person->goForAWalk();
}
public function testKillSomeone() {
$brain = new MockBrain($this);
$brain->setReturnValue('considerAction', false);
$person = new Person($brain);
$this->assertFalse($person->killSomeone());
}
}
Herein lies my issue with creating a DI of any sort as a Singleton. Within the context of Person, if I need to utilize a DI container to handle lookups I don't need to know about everything else that's been registered before me. Pico's coders have already written about this at Container Instantiation and Container Dependency and they are definitely more articulate than I could be.
At some point, Container Dependency has to happen. Even if it's at your index.php that sets the container up, at that point you become dependent on it to some degree. An example where Container Dependency would useful and not an anti-pattern is in the case of third party library. Let's use a data access object, it might want to offer a configuration means to allow you to specify which type of driver to use (driverType() for example). It could then use DI to figure out which drivers to insert into the various objects that it creates as it goes about is normal business. The drivers are all based on interfaces anyhow (or should be) so they can be interchanged without any issue. In this case, your DAO doesn't need to know about the Brain implementations you have registered for Person; it needs to keep track of its own DI. Likewise, from outside you don't need to know what the DAO is doing internally, just that it's handing out what you expect.
Have I won you over?
-
Sep 11, 2005, 10:40 #70
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by ghurtado
My bootstrap looks like:
PHP Code:require_once 'setup.php';
session_start();
$pico = new DefaultPicoContainer;
ApplicationController::registerComponents($pico);
ApplicationController::processActions($pico);
$page_ctrlr = new ParameterDispatchController;
$page_ctrlr->setParameterName(VIEW);
ApplicationController::addPages($pico, $page_ctrlr);
$page_ctrlr->start();
So far, we only have one instance of the DI container active, so you could just make it a singleton, right? I think the reason for keeping the DI container an instance variable is for testing code.
In my tests, I have some code for each action which validates the conditions for dispatching to that particular action class. Here is a custom assertion for this application which performs this check.
PHP Code:protected function assertDispatch() {
$post = new MockPost($this);
$post->setReturnValue('hasKey', true, array(ACTION));
$post->expectArguments('hasKey', array(ACTION));
$post->setReturnValue('get', $this->actionRequest, array(ACTION));
$post->expectArguments('get', array(ACTION));
$mock_action = 'Mock'.$this->actionClass;
$this->assertTrue(class_exists($mock_action));
if (class_exists($mock_action)) {
$action = new $mock_action($this);
$action->expectOnce('process');
$action->expectCallCount('process', 1);
$pico = new DefaultPicoContainer;
ApplicationController::registerComponents($pico);
$pico->unregisterComponent('Post');
$pico->registerComponent(new InstanceComponentAdapter($post, 'Post'));
$this->assertIdentical($post, $pico->getComponentInstance('Post'));
$pico->unregisterComponent($this->actionClass);
$pico->registerComponent(new InstanceComponentAdapter($action, $this->actionClass));
$this->assertIdentical($action, $pico->getComponentInstance($this->actionClass));
ApplicationController::processActions($pico);
}
$post->tally();
$action->tally();
}
Now one might argue that a singleton DI containter with a "clear()" method would be enough, but I somehow feel safer and more confident of less potential test interference with separate instances.Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
Sep 11, 2005, 11:14 #71
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I've refactored the code so that it acts like a loose singleton - in that you can get the singleton instance using DI::getInstance(), or you can get your own instance with new DI(); and they won't interfere with eachother. The singleton instance is only created if you make a call to DI::getInstance(), so there shouldn't be any extra overhead.
Here are a couple of snippets from the testcases:
PHP Code:function test_with_new_instance () {
$di = new DI();
$di->register(
'order',
'return new MyOtherOrder();');
// Use the same instance
$order =& $di->get('order');
$this->assertEqual($order->save(), 'Other order saved!');
}
function test_with_singleton_instance () {
// implicitly create the singleton instance
$di =& DI::getInstance();
$di->register(
'order',
'return new MyOtherOrder();');
unset($di);
// retrieve the singleton instance
$di =& DI::getInstance();
$order =& $di->get('order');
$this->assertEqual($order->save(), 'Other order saved!');
}
I'm running PHP4.4 and PHP5.0.4, I'd appreciate if anyone could test with the PHP5.1 RC1, I'm not 100% sure about line 33 in dependency_injector.php in that version.
Thanks,
DouglasHello World
-
Sep 11, 2005, 11:28 #72
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
- The developers warn us of the dangers of using independent instances of the container, such as when you instantiate it directly inside of a dependent class, or in a unit test. This is indeed an unwanted, obscure dependency (I agree with all of that so far). What they don't tell you is that this pitfall is only made possible because multiple instances of the container can be instantiated anywhere in your code.
- If you read their take on the Singleton it is immediately obvious that they consider the singleton an anti-pattern, and as such, Pico has been designed not to be a Singleton and allow multiple container instances.
You don't have to give this much thought to realize that if they had required for the container to be a Singleton, they would have been able to eliminate not one, but at least three "anti-patterns" (or in other words "ways to really screw it up using Pico") from their list. If I only allow one single instance of the container anywhere in my application I dont have to worry about classes internally or obscurely using the container, since they will still be referring to the same container all throughout the app. This may (is) still be a bad practice in general, but at least now I don't have any side effects from it.
Originally Posted by Travis S
It is the same reason why we don't hardcode the database username and password string everywhere throughout our application, and instead we put it into a configuration file: our applications are all still dependent on that information, but when you make it that easy to change, the dependance is effectively managed (or "neutralized" if you will)
As far as dependence on the container itself I would argue that there is no dependence whatsoever using Dependency Injection (or at least a proper implementation of it). A well-used DI container can be swaped for any other with a completely different interface and implementation with no side effects.
Originally Posted by Travis S
PHP Code:DI::register(
'driver',
'return new MysqlDriver();');
// or
/* DI::register(
'driver',
'return new PostgreSqlDriver();'); */
// or
/* DI::register(
'driver',
'return new MSSqlDriver();'); */
DI::register(
'brain',
'return new BrainDao(DI::get("driver"));');
DI::register(
'person',
'return new Person(DI::get("brain"));');
Originally Posted by Travis S
Originally Posted by Travis S
But thanks for your patience, I am enjoying this discussion greatly.
Garcia
-
Sep 11, 2005, 11:56 #73
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by ghurtado
PHP Code:function &getInstance () {
static $instance;
if ( isset($this) && is_a($this, 'DI')) {
return $this;
}
if ( !isset($instance) ) {
$instance = new DI();
}
return $instance;
}
DouglasHello World
-
Sep 11, 2005, 12:45 #74
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I hope I don't gloss over too much, but I believe this makes the point I'm interested in and where we're diverging in opinion:
Originally Posted by ghurtado
To continue the DAO use, I might do something like this:
PHP Code:$dm = new DependencyManager();
// just using generals here, not the syntax I've implemented in the code I linked to earlier...
$dao = new MyDAO();
$dao->useDriver('mysql');
$dm->register('dao', $dao);
$dm->register('brain', 'SmartBrain');
$dm->register('person', 'MyPerson');
On a slightly different topic...
One of the big things I don't like about DI is the configuration steps. Too often, those seem to be put forward as an integral part of DI which I don't fully agree with. It seems to me that the configuration of the container is an implementation specific thing. I could just as easily hard code my own internal container, and expose it. That's actually one area that the underlying code of Pico (php) has got right. There are two container interfaces - the PicoContainer and the MutablePicoContainer. If I already know how my container needs to be configured and I don't want it being messed with (in the case of the DAO above, for example, where new options might be discovered by attempting to locate files in a given path), I should only implement PicoContainer and just expose it for loading classes.
Originally Posted by ghurtado
Originally Posted by ghurtado
-
Sep 11, 2005, 21:19 #75
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Bookmarks