Simple zend-servicemanager

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Simple zend-servicemanager

Skar
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Skar
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.



Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Skar
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.





Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

shaferw
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin

On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;tim@timdev.com&#39;);" target="_blank">tim@...> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;sskarr@gmail.com&#39;);" target="_blank">sskarr@...> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;tim@timdev.com&#39;);" target="_blank">tim@...> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;sskarr@gmail.com&#39;);" target="_blank">sskarr@...> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.





Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Marco Pivetta
Note that the proposed DI config from Skar seems to be what Zend\Di is.

If it needs to be brought up, then it needs a clear specification, and a very rigid and inflexible list of limitations to prevent feature creep (yes, that happens a lot, sadly).


On 19 June 2016 at 04:23, Westin Shafer <[hidden email]> wrote:
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin


On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.






Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Skar
Hi,

Marco, how do you do it yourself for now?

On 19 June 2016 at 11:21, Marco Pivetta <[hidden email]> wrote:
Note that the proposed DI config from Skar seems to be what Zend\Di is.

If it needs to be brought up, then it needs a clear specification, and a very rigid and inflexible list of limitations to prevent feature creep (yes, that happens a lot, sadly).


On 19 June 2016 at 04:23, Westin Shafer <[hidden email]> wrote:
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin


On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.







Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Marco Pivetta
I currently define factories - it's quick and easy to introspect, while configs are much harder to debug.


On 19 June 2016 at 10:55, Skar <[hidden email]> wrote:
Hi,

Marco, how do you do it yourself for now?

On 19 June 2016 at 11:21, Marco Pivetta <[hidden email]> wrote:
Note that the proposed DI config from Skar seems to be what Zend\Di is.

If it needs to be brought up, then it needs a clear specification, and a very rigid and inflexible list of limitations to prevent feature creep (yes, that happens a lot, sadly).


On 19 June 2016 at 04:23, Westin Shafer <[hidden email]> wrote:
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin


On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.








Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Marco Pivetta
It is actually worth trying, but it needs very good support:

 * simple, clear and well defined rules
 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS
 * debugging support: container must produce meaningful exceptions about type compatibility issues and similar, and config-driven makes this typically hard
 * container must be compilable and analyzable via static introspection tools (IDEs, usually)



On 19 June 2016 at 11:03, Tim Lieberman <[hidden email]> wrote:
I do the same, for the most part.  Factories are easy to write, and easy to read.  Config-driven instantiation seems like a lot of complexity and cognitive overhead for no obvious gain.  

On Sun, Jun 19, 2016 at 1:57 AM, Marco Pivetta <[hidden email]> wrote:
I currently define factories - it's quick and easy to introspect, while configs are much harder to debug.


On 19 June 2016 at 10:55, Skar <[hidden email]> wrote:
Hi,

Marco, how do you do it yourself for now?

On 19 June 2016 at 11:21, Marco Pivetta <[hidden email]> wrote:
Note that the proposed DI config from Skar seems to be what Zend\Di is.

If it needs to be brought up, then it needs a clear specification, and a very rigid and inflexible list of limitations to prevent feature creep (yes, that happens a lot, sadly).


On 19 June 2016 at 04:23, Westin Shafer <[hidden email]> wrote:
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin


On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.










Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

GianArb
This post has NOT been accepted by the mailing list yet.
In reply to this post by Skar
We are using a factory for each service, controller that requires something to work.. It's another class but you can test it easier and also your service without service locator in my opinion it's easy to test.

2016-06-19 1:02 GMT+01:00 Skar [via Zend Framework Community] <[hidden email]>:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.




If you reply to this email, your message will be added to the discussion below:
http://zend-framework-community.634137.n4.nabble.com/Simple-zend-servicemanager-tp4662889.html
To start a new topic under ZF Contributor, email [hidden email]
To unsubscribe from Zend Framework Community, click here.
NAML



--
Gianluca Arbezzano
www.gianarb.it
Gianluca Arbezzano aka GianArb
www.gianarb.it
Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Axel H
In reply to this post by Marco Pivetta

This seems to be more of Auto-Wiring with configured injections, which is the domain of Zend-Di. I am already working on this approach and I'm almost done with it:

https://github.com/zendframework/zend-di/pull/6


Marco Pivetta <[hidden email]> schrieb am So., 19. Juni 2016, 11:05:
It is actually worth trying, but it needs very good support:

 * simple, clear and well defined rules
 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS
 * debugging support: container must produce meaningful exceptions about type compatibility issues and similar, and config-driven makes this typically hard
 * container must be compilable and analyzable via static introspection tools (IDEs, usually)

On 19 June 2016 at 11:03, Tim Lieberman <[hidden email]> wrote:
I do the same, for the most part.  Factories are easy to write, and easy to read.  Config-driven instantiation seems like a lot of complexity and cognitive overhead for no obvious gain.  

On Sun, Jun 19, 2016 at 1:57 AM, Marco Pivetta <[hidden email]> wrote:
I currently define factories - it's quick and easy to introspect, while configs are much harder to debug.


On 19 June 2016 at 10:55, Skar <[hidden email]> wrote:
Hi,

Marco, how do you do it yourself for now?

On 19 June 2016 at 11:21, Marco Pivetta <[hidden email]> wrote:
Note that the proposed DI config from Skar seems to be what Zend\Di is.

If it needs to be brought up, then it needs a clear specification, and a very rigid and inflexible list of limitations to prevent feature creep (yes, that happens a lot, sadly).


On 19 June 2016 at 04:23, Westin Shafer <[hidden email]> wrote:
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin


On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.









Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Axel H
In reply to this post by Marco Pivetta


Marco Pivetta <[hidden email]> schrieb am So., 19. Juni 2016, 11:05:
It is actually worth trying, but it needs very good support:

 * simple, clear and well defined rules
 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS
 * debugging support: container must produce meaningful exceptions about type compatibility issues and similar, and config-driven makes this typically hard
 * container must be compilable and analyzable via static introspection tools (IDEs, usually)

On 19 June 2016 at 11:03, Tim Lieberman <[hidden email]> wrote:
I do the same, for the most part.  Factories are easy to write, and easy to read.  Config-driven instantiation seems like a lot of complexity and cognitive overhead for no obvious gain.  

On Sun, Jun 19, 2016 at 1:57 AM, Marco Pivetta <[hidden email]> wrote:
I currently define factories - it's quick and easy to introspect, while configs are much harder to debug.


On 19 June 2016 at 10:55, Skar <[hidden email]> wrote:
Hi,

Marco, how do you do it yourself for now?

On 19 June 2016 at 11:21, Marco Pivetta <[hidden email]> wrote:
Note that the proposed DI config from Skar seems to be what Zend\Di is.

If it needs to be brought up, then it needs a clear specification, and a very rigid and inflexible list of limitations to prevent feature creep (yes, that happens a lot, sadly).


On 19 June 2016 at 04:23, Westin Shafer <[hidden email]> wrote:
A friend of mine wrote this module to make zf config work like symfonys.  You can see if that's more to your liking then building out a ton of factories for your services.  https://github.com/reliv/zf-config-factories

Westin


On Saturday, June 18, 2016, Skar <[hidden email]> wrote:
Ok, I think about it. Thank you.

And maybe someone has another interesting ideas?

On 19 June 2016 at 05:58, Tim Lieberman <[hidden email]> wrote:
Performance hasn't been a concern for this project (which is an internal line-of-business app).  However, if it became an issue, you could start optimizing by creating concrete controllers for frequently invoked actions.

On Sat, Jun 18, 2016 at 5:55 PM, Skar <[hidden email]> wrote:
Hi,

What about the performance of such solution?

On 19 June 2016 at 05:45, Tim Lieberman <[hidden email]> wrote:
I've been gone the abstract factory (using reflection) route and it seems to work well.  I'm not sure why you think that "will push the container into [the] action".

Here's my AbstractActionFactory from a recent expressive project:


On Sat, Jun 18, 2016 at 5:41 PM, Skar <[hidden email]> wrote:
Hi all,

I have a question about 'new' SM, how to work without ServiceLocatorInterface?
I understand why it's was removed, but don't understand how to work comfortably without it.

Many services requires dependencies, and I see only one way - create a factory for each service.
For example: actions in Expressive - I need create 10 actions and create 10 factories for each action... Or create one abstract factory that will push the container into action... But it's wrong...

And I can create closures, but it can't be cached in config.

So, I need in an explanation how easy to work with it.


And I think to do simple dependencies configuration like:

'simple' => [
    'dep-name' => [
        'class' => MyService::class,
        'params' => [
            'Dep1',
            'Dep2',
        ]
    ]
]
It's like a factory:

'dep-name' => function($container) {
    return new MyService($container->get('Dep1'), $container->get('Dep2'));
}

What do you think about it?
I can do it.

Thanks.









Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Stefano Torresi-2
If you really don't like Zend\SM, you could always try a different ContainerInterop implementation, like PHP-DI which provides auto-wiring and configuration driven setup.
Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Axel H
In reply to this post by Marco Pivetta

 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS

True, that's why I removed the default Setter injections and param guessing hell for example.
The primary is Constructor injection and only the construction params can be passed. Need more flexibility? Use a service factory.

I'll keep my mouth shut about the SM integration code of Zend Di 2.x ...
Let's dig a grave deep enough for it to never come back ..


Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Skar
So... we have two libs with similar functions but the first use factories and the second use configs?..
Or I misunderstood?

On 19 June 2016 at 16:42, Axel H <[hidden email]> wrote:

 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS

True, that's why I removed the default Setter injections and param guessing hell for example.
The primary is Constructor injection and only the construction params can be passed. Need more flexibility? Use a service factory.

I'll keep my mouth shut about the SM integration code of Zend Di 2.x ...
Let's dig a grave deep enough for it to never come back ..



Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Skar
> If you really don't like Zend\SM

I really like Zend\SM, and I don't want to write (yet another) own implementation, because Zend\SM is currently the closest thing to what I need.

On 19 June 2016 at 16:55, Skar <[hidden email]> wrote:
So... we have two libs with similar functions but the first use factories and the second use configs?..
Or I misunderstood?

On 19 June 2016 at 16:42, Axel H <[hidden email]> wrote:

 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS

True, that's why I removed the default Setter injections and param guessing hell for example.
The primary is Constructor injection and only the construction params can be passed. Need more flexibility? Use a service factory.

I'll keep my mouth shut about the SM integration code of Zend Di 2.x ...
Let's dig a grave deep enough for it to never come back ..




Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Axel H
In reply to this post by Skar
Yes sort of. Both provide IoC with different approaches. While the SM uses a factory driven, code everything approach - DI provides auto-wiring. That means no factory code, but analyzing the classes, detecting the dependencies and injecting them (additionally instantiating them).

IMHO both concepts become extremely powerful when brought together, so you can benefit from both worlds. That's one of the reasons for my PR.

But there are some purists out there who define auto-wiring evil the other ones think writing factories all the time is a waste of time, so its a good idea to keep the separated.


Skar <[hidden email]> schrieb am So., 19. Juni 2016, 13:55:
So... we have two libs with similar functions but the first use factories and the second use configs?..
Or I misunderstood?

On 19 June 2016 at 16:42, Axel H <[hidden email]> wrote:

 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS

True, that's why I removed the default Setter injections and param guessing hell for example.
The primary is Constructor injection and only the construction params can be passed. Need more flexibility? Use a service factory.

I'll keep my mouth shut about the SM integration code of Zend Di 2.x ...
Let's dig a grave deep enough for it to never come back ..



Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Skar
> when brought together

How? =)

On 19 June 2016 at 17:04, Axel H <[hidden email]> wrote:
Yes sort of. Both provide IoC with different approaches. While the SM uses a factory driven, code everything approach - DI provides auto-wiring. That means no factory code, but analyzing the classes, detecting the dependencies and injecting them (additionally instantiating them).

IMHO both concepts become extremely powerful when brought together, so you can benefit from both worlds. That's one of the reasons for my PR.

But there are some purists out there who define auto-wiring evil the other ones think writing factories all the time is a waste of time, so its a good idea to keep the separated.


Skar <[hidden email]> schrieb am So., 19. Juni 2016, 13:55:
So... we have two libs with similar functions but the first use factories and the second use configs?..
Or I misunderstood?

On 19 June 2016 at 16:42, Axel H <[hidden email]> wrote:

 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS

True, that's why I removed the default Setter injections and param guessing hell for example.
The primary is Constructor injection and only the construction params can be passed. Need more flexibility? Use a service factory.

I'll keep my mouth shut about the SM integration code of Zend Di 2.x ...
Let's dig a grave deep enough for it to never come back ..




Reply | Threaded
Open this post in threaded view
|

Re: Simple zend-servicemanager

Axel H

https://github.com/tux-rampage/zend-di/blob/zf3/src/Module.php (Mvc)
Or
https://github.com/tux-rampage/zend-di/blob/zf3/src/ConfigProvider.php (Expressive)

It adds an abstract service factory to SM and sets the SM as IoC container for the Injector


Skar <[hidden email]> schrieb am So., 19. Juni 2016, 14:10:
> when brought together

How? =)

On 19 June 2016 at 17:04, Axel H <[hidden email]> wrote:
Yes sort of. Both provide IoC with different approaches. While the SM uses a factory driven, code everything approach - DI provides auto-wiring. That means no factory code, but analyzing the classes, detecting the dependencies and injecting them (additionally instantiating them).

IMHO both concepts become extremely powerful when brought together, so you can benefit from both worlds. That's one of the reasons for my PR.

But there are some purists out there who define auto-wiring evil the other ones think writing factories all the time is a waste of time, so its a good idea to keep the separated.


Skar <[hidden email]> schrieb am So., 19. Juni 2016, 13:55:
So... we have two libs with similar functions but the first use factories and the second use configs?..
Or I misunderstood?

On 19 June 2016 at 16:42, Axel H <[hidden email]> wrote:

 * clear restrictions, because the last time we attempted auto-wiring (for example) ended up with EXPLOSIONS

True, that's why I removed the default Setter injections and param guessing hell for example.
The primary is Constructor injection and only the construction params can be passed. Need more flexibility? Use a service factory.

I'll keep my mouth shut about the SM integration code of Zend Di 2.x ...
Let's dig a grave deep enough for it to never come back ..