Lets talk about DI about cakephp-service-layer HOT 10 CLOSED

The code already supports passing args to the constructor.

$releaser = $this->loadService('Releaser', ['firstarg', '2ndarg', '...']);

If you're using a DIC you don't need the trait at all and the above line will be completely handled by the DIC system. I have intentionally not added any form of specific DI. It is up to the user to implement this as DIC, locator or even doing it manually.

I'm also about to rename a folder in the plugin, from Model/Business to DomainModel.

from cakephp-service-layer.

@dereuromark my plan is to suggest this plugin https://github.com/robotusers/cakephp-di but not making it a hard dependency. It features PSR-11 and my idea is to show how to use cakephp-di with this plugin. But I'm not going to add any hard requirement on a DIC to this plugin. Does that answer your question?

from cakephp-service-layer.

Maybe it suffices to add a docs example for testing and mocking.
E.g. integration tests of a controller that somewhere along the line uses a service with Git/Jira/Travis etc and needs to mock that specific subservice to return a specific payload.

from cakephp-service-layer.

I would like to have sth more explicit in terms of https://matthiasnoback.nl/2019/03/hand-written-service-containers/ to work along side this if possible.
Do you think we could add this somewhere?

This would also solve the related issues I am having here.

from cakephp-service-layer.

@dereuromark can you be a little more concrete of what you want?

from cakephp-service-layer.

@dereuromark the article is just about a container that explicitly contains services, this is nothing special? Also I disagree with could retrieve a controller from the service container. A controller should use services, not being pulled from a service container, assuming we mean the same. There are application layer services, what CakePHP components could be seen as, and domain services. The closest, but I would disagree in this case, Cake has, are the behaviors.

from cakephp-service-layer.

Sure, that part I didnt mean. Lets leave the controller part out of it.
I meant the rest, factory (explicit or via config file).

If you look again at my initial code piece above, that uses Connection inside Git inside Releaser etc.
How would this be done currently using this Service lib?
Would all be separate services and we just combine them?
Or can we use a basic factory pattern to assemble them?

A concrete example (maybe even in docs) might help me understand what you mean with "it all works already".

from cakephp-service-layer.

@dereuromark simple DI as any container would do it: Use auto-wire, annotations or manually configure it in your container config.

class SomeService {
    public function ___construct(
        Foo $foo,
        Bar $bar,
        Something $something,
    ) {
        $this->foo = $foo;
        $this->bar = $bar;
        $this->something = $something;
    }
}

$instance = Container::get(SomeClass::class);

Your DI container will auto write or you'll do it via your container config.

If you want factories and locators, the usual concrete cake stuff, then do it in your app, because these classes will be app specific. You are looking for complexity to solve where none is.

from cakephp-service-layer.

@dereuromark in your case just wire your DI up to return mocks from your container and it will do all the magic transparently. Your issue are also them whole mocks itself not really the DI. A lot nested objects as mocks just suck. However, using DI you can write them once and let them return automatically when needed. It will simply auto resolve them.

from cakephp-service-layer.

@dereuromark can we close this as well or continue to discuss it?

from cakephp-service-layer.