What are the Slack Archives?
Itβs a history of our time together in the Slack Community! Thereβs a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.
Because this space is not active, you wonβt be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..
I got a general question regarding `DependencyProviders` and `Factories` in Spryker: As far as I und
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?
Comments
-
Spryker does not follow standards, standards follow spryker.
As a joke - if you search through vendor, you will find factory of factory.
0 -
@U010DNAA3QW the
DependencyProvider
only makes the inter-module dependencies available0 -
everything that is instantiated there are just proxy classes, nothing that requires dependencies
0 -
yu are basically mocking away external dependecies, when you mock the plugin stack configurations
0 -
and factories of factories are actually not that exotic in the wild π€ maybe naming could be improved
0 -
can i use that as a slogan, @UNBSW8S8K
Spryker does not follow standards, standards follow spryker.
π
0 -
@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.0 -
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.
0 -
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.
0 -
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
0 -
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 π
0 -
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)
0 -
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 π
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 75 Spryker News
- 924 Developer Corner
- 783 Spryker Development
- 88 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 35 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 25 Job Opportunities
- 3.2K π Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 70 Spryker Safari Questions
- 50 Random