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

U01A1HDSVS8

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

Chemaclass

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

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)

Unknown

EntityTransfer approach is deprecated.

U01A1HDSVS8

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

Chemaclass

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

@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

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

Ahmed Sabaa

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

U01A1HDSVS8

Thank you very much @ULL9CA6CB!

Chemaclass

This makes sense now, thanks 👌🏻

U01A1HDSVS8

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

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”