Calling Developers!
We are reenergizing our code contribution process! Learn More

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..

Hello everyone, what do you think is a the preferable way to provide hydration logic to other module

Options
UPWG9AYH2
UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet

Hello everyone,
what do you think is a the preferable way to provide hydration logic to other modules? For example there is a new project level module with a new table which is connected to the spy_customer table … in the new modules repository findXyzById method the entity of the new table should be returned, but also the mapped(!) connected customer … since the customer data itself is already mapped in the customer module, it would not make much sense to duplicate this mapping logic, instead using the existing logic from the customer module would be preferable. But calling a customer modules facade method from the repository of the new module seems to be a bit odd to me …
I see, many spryker modules just doing mapping logic again in the corresponding modules … but what do you think? Do you have other approaches? Maybe i also miss something 😉 Best regards

Comments

  • U03TREBSX44
    U03TREBSX44 Posts: 9 🧑🏻‍🚀 - Cadet
    Options

    Hello, in the context of the glue api, one option would be to use relationship plugins. When requesting data about the customer you could use a relationship plugin to also access or include data from another module. not sure if this helps?

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    Hi Andy,
    it’s in the context of the Persistence layer … so there is a lot of mapping stuff, for example for customers … mapping addresses, locales etc … since this is already done in the customer itself, i wonder if there is a “clean approach” to reuse this stuff in some other module again … but i guess, the only way would be to do it via a facade call with which i am not sure if this is an appropriate way …

  • UPWG9AYH2
    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    Options

    So basically its the question if the repository then is responsible for mapping stuff using another facade … feels very unclean … so i think, i miss something ^^