MappedSuperClass et héritage de classes d'entités

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous,
Je n'arrive pas à comprendre quel est l'utilité de la MappedSuperClass de Doctrine. Quand on lit la doc, on lit notamment :

A mapped superclass cannot be an entity, it is not query-able and persistent relationships defined by a mapped superclass must be unidirectional (with an owning side only). This means that One-To-Many associations are not possible on a mapped superclass at all. Furthermore Many-To-Many associations are only possible if the mapped superclass is only used in exactly one entity at the moment. For further support of inheritance, the single or joined table inheritance features have to be used.

Personnellement, je me dis : o_O
Pourquoi toutes ces restrictions alors qu'un simple héritage de classe retourne la même chose niveau PHP, produit le même SQL et s'utilise de la même manière au niveau du QueryBuilder ? J'imagine qu'il doit y avoir des avantages de performance, mais la Doc n'en parle pas.

Bien sûr, je ne peux pas non plus me servir des Single/Class Table Inhreritance, du fait de cette relation 1,N bidirectionnelle que j'ai dans ma classe abstraite et qui causerait des problèmes de performance ("If the target-entity of a many-to-one or one-to-one association is a CTI entity, it is preferable for performance reasons that it be a leaf entity in the inheritance hierarchy, (ie. have no subclasses). Otherwise Doctrine CANNOT create proxy instances of this entity and will ALWAYS load the entity eagerly.")

Du coup, je compte me diriger vers l'héritage, et tant pis pour Doctrine… Est-ce que vous avez des idées ?

+0 -0

Salut !

Une des utilisations courantes que je remarque pour les MappedSuperclass, c'est pour regrouper des champs communs à plusieurs entités qui n'héritent pas "en cascade", et en même temps forcer les utilisateur à implémenter une classe spécialisée pour leur application, tout en s'assurant que les éléments nécessaires sont présents. Un peu comme une interface, seulement, on a aussi les accesseurs et mutateurs que l'on ne peut pas mettre dans ces derniers, et je ne pense pas que Doctrine accepte des annotations dans des interfaces  ^^

Evitez qu'on vous dise de les lire : FAQ PHP et Symfony 2Tutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+0 -0
Auteur du sujet

Salut et désolé pour le temps de réponse… Dans les classes abstraites non persistées (dont notre classe va hériter), les annotations Doctrine passent tranquillement, donc je pense que ca doit être pareil pour les interfaces.

Cela dit, en réfléchissant un peu plus à mon problème (pourquoi diable autant de restrictions de Doctrine sur une MappedSuperClass) cette semaine, j'ai fini par comprendre certaines restrictions, mais tout n'est pas encore clair dans ma tête. Donc pour finir, j'ai pris un schéma de Class-Table Inheritance, et tant pis pour les performances Doctrine pour l'instant. :p

+0 -0

Dans les classes abstraites non persistées (dont notre classe va hériter), les annotations Doctrine passent tranquillement, donc je pense que ca doit être pareil pour les interfaces.

melepe

A ceci près que dans les interfaces, tu ne peux pas spécifier d'attributs, seulement des constantes, si je ne me trompe pas. Du coup, les interfaces ne servent pas à grand-chose pour Doctrine…

Édité par Ymox

Evitez qu'on vous dise de les lire : FAQ PHP et Symfony 2Tutoriel WAMP • Cliquez 👍 pour dire merci • Marquez vos sujets résolus

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte