Aura.Di, same class, 2 distinct instances

35 views
Skip to first unread message

Chris Johnson

unread,
Jan 30, 2016, 12:00:09 AM1/30/16
to The Aura Project for PHP
I'm trying to wrap my head around how to use Aura.Di.  I understand I use it to pre-wire the creation paths for all the objects my app will need up front.  I also understand most of the documentation and examples.  ;-)

But I'm not sure how to go about solving the following situation.

I have two service classes that support the domain logic for my application.  One must connect to an LDAP.  The other connects to a proprietary socket server.  Each must get its configuration information from different configuration files (these files are shared by other applications and are part of a larger infrastructure, so there's no changing this requirement).  The file is specified via a constructor parameter.  If I just create the needed objects and inject them by hand, my code might look something like the following:

<?php
$ldapConfig
= new Config('ldap.cfg');  // instance to read LDAP configuration file
$ldap      
= new Ldap($ldapConfig);   // inject Config object into actual LDAP adapter


$socketConfig
= new Config('socket.cfg');  // instance to read socket server configuration file
$socket      
= new Socket($socketConfig); // inject Config object into actual socket adapter
?>

I can figure out to specify wiring this up for one configuration / adapter pair, or even to re-use the same configuration object in multiple other objects.  But I can't figure out how to have Aura.Di construct the two instances using two different parameters for the same class.

Maybe I'm just over thinking this.  It's entirely possible this is very simple but I'm somehow missing how it's done.

Example wiring code would be highly welcomed.  Any help is appreciated.

Hari K T

unread,
Jan 30, 2016, 12:17:26 AM1/30/16
to aur...@googlegroups.com
Hey Chris Johnson,

Depending upon v2 and v3 there may be a few adjustments you may need to do. I believe there may be nill though ;) .

Below is what it looks like

$di->set('ldap_config', $di->lazyNew('Config',
    [
        'config-param-variable' => $di->lazyRequire('ldap.cfg'),
    ]
));

$di->set('socket_config', $di->lazyNew('Config',
    [
        'config-param-variable' => $di->lazyRequire('socket.cfg'),
    ]
));

$di->set('ldap', $di->lazyNew(
        'Ldap',
        [
            'config-param-variable' => $di->lazyGet('ldap_config')
        ]
    )
);

$di->set('socket', $di->lazyNew(
        'Socket',
        [
            'config-param-variable' => $di->lazyGet('socket_config')
        ]
    )
);

I believe this is what it is mentioned https://github.com/auraphp/Aura.Di#instance-specific-setter-values .

The only thing you need to change will be `config-param-variable` with what your class constructor variable you have used.

I believe you know what I am telling :) .

Hope that helps

Thank you



Hari K T

You can ring me : +91 9388 75 8821

Skype  : kthari85
Twitter : harikt

--
You received this message because you are subscribed to the Google Groups "The Aura Project for PHP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to auraphp+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hari K T

unread,
Jan 30, 2016, 12:19:21 AM1/30/16
to aur...@googlegroups.com
Probably you may not need $di->lazyRequire . Change it with only value. lazyRequire will try to require the file.

Probably your Config class may need only name I guess.

Thanks!

Hari K T

You can ring me : +91 9388 75 8821

Skype  : kthari85
Twitter : harikt

Chris Johnson

unread,
Feb 1, 2016, 3:36:19 PM2/1/16
to The Aura Project for PHP
Thanks, Hari K T!  I now see how to do different parameter values with different instances of my objects.

Unfortunately, it seems that using dependency injection containers (DICs) are sometimes just as bad as the problem they aim to solve.  The DIC solves inter-object coupling, making the program less tightly coupled, which is good.  Doing so improves reusability and testability.

But at the same time, it introduces coupling to another object (the DIC itself), and worse, it breaks encapsulation:  now each application's DIC must know about parameter names and values that only one object in the entire application -- a library dependency object -- needs to know about.  We have spread knowledge to remote places where it should not exist.  And the code to do so is obfuscated by the non-PHP syntax (instead, string values) of the DIC.

This looks like a difficult problem to solve.  Everyone uses DIC; it's the accepted "correct" solution, even though it introduces new problems while solving others.  
Reply all
Reply to author
Forward
0 new messages