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..
*Tech-question regarding the role of the QueryContainer in Spryker* Having a `Repository` and an `E
Tech-question regarding the role of the QueryContainer in Spryker
Having a Repository
and an EntityManager
, does it makes sense to use the QueryContainer
in my Business Layer?
I mean, we could agree that the Repository
is used to get/find information, and that the EntityManager
is used to manipulate information from your Business Layer (always using their interfaces). But where is the room to play for the QueryContainer
in the Business Layer? Is there actually any room for it?
I am just curiousโฆ I think there is no ๐ง
I understand the QueryContainer
as a place to have some queries which are going to be used by any other Persistence Layer logic, but not in the Business Layer. Or am I missing something here? I would like to confirm all these ideas ๐ก
Comments
-
At the beginning we had no repositories and entity managers. Query container is a relic from those times. It still exists but has no place in new modules.
0 -
Nice ๐ Then, it doesnโt makes sense to use it in our Pyz modules. I mean, if we can choose if we want to create a QueryContainer or a Repository, we should simply use Repository (or an EntityManager) instead, right?
0 -
QueryContainer is a completely deprecated concept, it had conceptual problems of leaking database implementations outside of modules, you can use them in project if they exist, you can also create them in your modules on Pyz if you want, but that is extremely not recommended (I feel like thereโs a better expression here) because of leaking concepts and domain encapsulation
0 -
This is exactly what I was thinking ๐๐ผ Now I got official-support for this argument. Thanks
0 -
There was one good thing about the query containers, though: They allowed for easy extension of queries on project level. Now with repositories the query and mapping parts are baked together in most cases making it hard to extend in any project situation (e.g. filter for an additional field). If the repositories would make use of the query containers we could actually have that extensibility. They would just need to get restricted to not leak outside the persistence layer.
0 -
good point Thomas - I do like queries in one place so that you do not repeat them all over if not necessary.
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 76 Spryker News
- 929 Developer Corner
- 787 Spryker Development
- 89 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
- 26 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