Alternative way to define InheritanceMap

[rsavuliak-macpaw]

I am wondering if there can be an alternative way to define InheritanceMap? Cause current one expects me to set an attribute on the target abstract class. However, for certain architectures like Onion, Clean Architecture and other layered examples this can be a violation of responsibility, when your classes "know" about classes from higher layer. It happens on mapping from DTO to Entity object. For example:

use Rekalogika\Mapper\Attribute\InheritanceMap;
use Domain\ConcreteClassA;
use Domain\ConcreteClassB;
use Domain\ConcreteClassC;
use Presentation\RequestAObjDTO;
use Presentation\RequestBObjDTO;
use Presentation\RequestCObjDTO;

#[InheritanceMap([
    RequestAObjDTO::class => ConcreteClassA::class,
    RequestBObjDTO::class => ConcreteClassB::class,
    RequestCObjDTO::class => ConcreteClassC::class,
])]
abstract class ConcreteClass
{
}

So in this case, to convert Presentation layer object into Domain layer object I have to define this mapping in the Domain layer. That means I will get an alert in architecture control tools like phparkitect/deptrac that my Domain layer has dependencies on Presentation layer.

I guess it would be nice to have a way to define this inheritance mapping on Presentation layer side, maybe it's possible to do this on the source class providing 2 attributes smth like SourceInheritanceMap and TargetInheritanceMap, depending if this class treats as a source or as a target? Or maybe pass it in Context for this specific mapping action. Just brainstorming 🤷‍♂️

P.S. Offtop, I see you've added support for ramsey/uuid - that's great, cause we are using it widely - can you pls create new release so we don't need to make "dev-master" dependency? 😉

[priyadi]

I have made a release with the ramsey/uuid support. Let me know if there's a problem.

Regarding your main issue, from what I observed, attributes are usually not considered in architectural constraints because the code will still work without the class used in the attributes, a case in point. However, I understand if not everyone feels the same way.

I used to have this in mind: if the target is abstract or an interface, then if a parent or an interface of the source has an InheritanceMap, it will be flipped and used as if the flipped InheritanceMap is on the target side. The upside is that we only need to maintain one InheritanceMap for bidirectional mapping. I'll see if this is possible.

But the long-term solution is a class metadata, so that everything that the attributes can do now will be possible using an external YAML configuration.

[priyadi]

I've implemented the reversed InheritanceMap in the linked PR. Now, you can add InheritanceMap to your DTOs, and it will be considered when you are mapping from the DTOs. Please test it to see if it is sufficient for your use case.