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

Good Morning, is there a reason to not return an *EntityTransfer from a facade?

Options
U01A1HDSVS8
U01A1HDSVS8 Posts: 17 🧑🏻‍🚀 - Cadet

Good Morning,
is there a reason to not return an *EntityTransfer from a facade?

Comments

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

    Because (db) entities should live only in the Persistence layer in order to avoid spreading those “write models” outside the module itself. That’s one of the reasons why you want to return only transfer objects, which are plain objects with data.

    Is not just for the Facade, but for the Repositories as well. You want to minimise the scope of the objects with Propel magic in order to make your code more predictable. For this reason, in your business layer you also want to use the repository/em interfaces which should return transfer objects as well.

    The only exception (in Spryker) is for Middleware. On which they “allow” to use propel entities for performance reasons.

    A great book that explains in details all of this is this one:
    Advanced Web Application Architecture 👀
    https://chemaclass.es/readings/advance-web-application-architecture/

  • U01A1HDSVS8
    U01A1HDSVS8 Posts: 17 🧑🏻‍🚀 - Cadet
    Options

    I'm not talking about Entity objects which would grant write access to the database but about those auto generated EntityTransfers which are Transfer Objects (thus no db write logic inside) that have the same fields as the corresponding EntityObject. (E.g. Generated\Shared\Transfer\SpyQuoteEntityTransfer NOT Orm\Zed\Quote\Persistence\SpyQuote)

  • EntityTransfer approach is deprecated.

  • U01A1HDSVS8
    U01A1HDSVS8 Posts: 17 🧑🏻‍🚀 - Cadet
    Options

    How do I know it is deprecated? https://documentation.spryker.com/docs/entity-manager So the whole page is deprecated?

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

    From my understanding:
    • EntityManager = save/update/delete (command)
    • Repository = get/find (query)
    ◦ get: returns something or Exception;
    ◦ find: returns something or null
    They receive primitives or TransferObjects, and return primitives or TransferObjects. The goal is isolate the scope of entity objects under the Persistence layer only.

    TL;DR: that docu-page that you shared is a bit unclear; specially with those SpyFooEntityTransfer stuff… Maybe the prefix on those examples is just leading to misinterpretation, or I understood that wrong, or is simply just wrong. I can’t tell.

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

    @U015S0C0V29 there are generated *EntityTransfers which are basically the same as propel classes but extend AbstractTransfer which disable their ability to update the database.

    @U01A1HDSVS8 The main reason is to avoid exposing the database representation of a domain object outside of its module. That is internal module knowledge and how we represent it in database is irrelevant for the business layer of other modules. Usually Domain Transfers are a bit more complicated than just database representation and we have the rule that those Transfers are dealt with the same way as propel objects (Do not leave facades)

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

    Ah! Thanks for clarifying that, @ULL9CA6CB. Is this “EntityTransfers” a new concept? I didn’t know them before

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

    Not a new concept though, but they are barely used really.

  • U01A1HDSVS8
    U01A1HDSVS8 Posts: 17 🧑🏻‍🚀 - Cadet
    Options

    Thank you very much @ULL9CA6CB!

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

    This makes sense now, thanks 👌🏻

  • U01A1HDSVS8
    U01A1HDSVS8 Posts: 17 🧑🏻‍🚀 - Cadet
    Options

    One more Questions though: Why are those EnitityTransfers there at all? The EntityManger could work with the Entity itself as it is in the Persitence Layer!?

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

    Good question 🙂
    As I said, rarely used. I think they are MAINLY used in infrastructural parts of P&S to avoid destroying the rule of “No facade should return a Propel object”