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

Options
Chemaclass
Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
in Slack General

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

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet
    Options

    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.

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
    edited April 2021
    Options

    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?

  • Ahmed Sabaa
    Ahmed Sabaa Senior Application Architect @Spryker Posts: 54 🧑🏻‍🚀 - Cadet
    Options

    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

  • Chemaclass
    Chemaclass Tech Lead Spryker Solution Partner Posts: 213 🧑🏻‍🚀 - Cadet
    edited April 2021
    Options

    This is exactly what I was thinking 👌🏼 Now I got official-support for this argument. Thanks :)

  • U01T075RRHD
    U01T075RRHD Posts: 118 🧑🏻‍🚀 - Cadet
    Options

    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.

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet
    Options

    good point Thomas - I do like queries in one place so that you do not repeat them all over if not necessary.

Categories