I got a general question regarding `DependencyProviders` and `Factories` in Spryker: As far as I und

U010DNAA3QW

I got a general question regarding DependencyProviders and Factories in Spryker: As far as I understood, the idea is that the DependencyProvider is responsible for solving dependencies to external modules and injecting them into the Container - the idea behind the Factory is to 1) actually give access to those external dependencies (through get* methods) and 2) create inner-module dependencies through create* methods (e.g. creating new instances of business models, or creating plugin hook arrays, etc). As far as I understood, the DependencyProvider should not instantiate new inner-module objects (e.g. business models), this is the job of the Factory. Is this correct?
If yes: We have cases in our project, where the DependencyProvider is actually instantiating new business objects (as an example, an array of PostProcessorHookPlugins), setting them in the Container, and the Factory is just grabbing those from the Container , instead of creating them himself. This has been done (as far as I can see) because we have integration tests which are overriding the Container dependencies through the DependencyHelper to change the behaviour of a Process (so it overrides the array of PostProcessorHookPlugins coming from the DependencyProvider inside of the integrationtest). Now my question: From an architectural point of view, is this against the concept behind DependencyProviders and Factories? Would it be more correct to refactor this, so that the PostProcessorHookPlugins actually are instantiated in the Factory, and the integration-test is mocking the Factory then instead of overriding the dependency?

UNBSW8S8K

Spryker does not follow standards, standards follow spryker.

As a joke - if you search through vendor, you will find factory of factory.

Unknown

@U010DNAA3QW the DependencyProvider only makes the inter-module dependencies available

Unknown

everything that is instantiated there are just proxy classes, nothing that requires dependencies

Unknown

yu are basically mocking away external dependecies, when you mock the plugin stack configurations

Unknown

and factories of factories are actually not that exotic in the wild 🤔 maybe naming could be improved

Unknown

can i use that as a slogan, @UNBSW8S8K

Spryker does not follow standards, standards follow spryker.

😄

Andriy Netseplyayev

@U010DNAA3QW your understandings are correct 👍! Regarding the plugin stacks in dependency providers:
the thing is, that such plugin stacks are mostly filled in with plugins coming from other modules, too. That’s the reason they are defined there.

Andriy Netseplyayev

plugins itself doesn’t have to be built by factories since they don’t have dependencies, so they can be easily instantiated right in dependencyProvider.

Andriy Netseplyayev

if you have a look at freshly installed project, what you will mostly see in Pyz - are bunch of overwritten DependencyProviders, that then wire things together, mostly via such plugin stacks.

Andriy Netseplyayev

Would it be more correct to refactor this

technically, you can build plugin stacks in the factory, “asking” dependencyProvider for external plugins only and that would be also a way to go. But it would be harder on the project side to extend such structure and require much more code (provide all the plugins from DP, and then overwrite factory). So this solution is to make it simpler

U010DNAA3QW

thanks for the infos so far 🙂 so, in this specific case, the plugin stack I am talking about only consists of plugins coming from the same module... so the DP is instantiating objects from its own module here, and this feels a bit dirty for me - because this is the job of the factory. that is why I am confused. but yeah, maybe its just easier then to use it in the integration test 🤷 but OK, I will leave it like this then currently 😄

Andriy Netseplyayev

in your case, you could have it in factory, unless you plan to keep extending the list and let plugins from other modules come in (or plugins from your current module will be moved to another one-s)

U010DNAA3QW

yes, but if it is in the Factory, I cannot so easily override the plugin stack in the integration test with the DependencyHelper... I think that is the reason why the original developer did it this way 😄