J'essaie de pratiquer une bonne conception et d'étendre l'entité de la doctrine. Ma classe élargie, le modèle fondamentalement, aura une logique d'entreprise supplémentaire + accès aux données de base de l'entité.
J'utilise la doctrine 2.2.1 & Zend Framework 1.11.4 & PHP 5.3.8 P>
Quand J'utilise DQL, Doctrine retourner avec succès l'entité modèle. Lorsque j'utilise la fonction de doctrine natif (), il ne renvoie rien: (. P>
Aide ... P>
Bootstrap.php strong>: p> ne fonctionne pas strud> em>: p> $qry = $qb
->select('u')
->from('Models\User','u');
3 Réponses :
Si je comprends la doctrine, Lire ce docs pour plus d'infos http://docs.doctrine-project.org/projects/doctrine-orm/fr/Latest/reference/Inheritance-Mapping.html entitymanager est responsable uniquement des entités persistantes et d'étendre les entités \ utilisateur avec modèle \ utilisateur créera un autre Entité (stockée dans la même table que celle indiquée dans DOCBLOCK), mais non gérée par EntityManager ou en collision avec elle parce que vous n'avez probablement pas mentionné @inheriCetType ("unique_table") dans entités \ utilisateur DocBLocks:
La mappeSuperClassbase doit être la base de toute autre entité, définit leurs propriétés et méthodes communes, les classes d'enfants sont des entités concrètes ... Exemple: GeneralUser est superclasse avec des champs courants, éditeur et superviseur l'étend avec leurs champs spécifiques tels que Editor.AssiencedTopics ou superviseur .topicstocheckout ... espérons que cela aide
Merci pour le commentaire. Relatif à mes besoins spécifiques: le mappeferclassbase doit contenir une logique commerciale? Fondamentalement, l'objectif principal est d'avoir une classe d'entité que la doctrine CLI peut réécrire et mettre à jour en fonction des défautions YAML. Et je veux pouvoir ajouter des fonctions commerciales avec Zend capacités à une classe extension sans soucis de la synchronisation et de la fusion. Si vous me le permettez, comment allez-vous aborder cette question?
J'ai supprimé et édité le premier commentaire, mais je ne vous ai pas vu de répondre. Pardon. Quoi qu'il en soit, je n'ai pas besoin de cette fonctionnalité. Je veux ajouter une fonction spécifique à une entité spécifique. Relatif à mon exemple, que la classe d'utilisateurs aurait des fonctions qui seront effectuées sur l'utilisateur. tels que sendpushnotifications, etc.
Vous souhaitez donc avoir toute la logique de stockage / CRUD dans vos entités \ User et toute la logique commerciale dans les modèles \ User? Dans ce cas, il n'ya aucune raison de garder votre modèle géré par Doctrine EntityManager car cela n'est évidemment pas une entité. Demandez à votre modèle plutôt d'utiliser l'entité au lieu de l'étendre comme: $ Modèle = nouveaux modèles \ user ($ entité); $ Modèle-> DosomeBusinessLogic ();
Oui, c'est la solution que je suis allé. Je voulais juste enregistrer le $ modèle = Nouveau modèles \ User ($ entité); et rendre le code beaucoup plus élégant .. apprécier l'aide!
@ohadwkn, ce serait génial si vous partagez votre exemple de code de solutions ici (modifiez simplement votre question), de sorte que d'autres ayant des problèmes identiques et similaires et des préoccupations peuvent le trouver utiles.
@ Ivanhušnjak Un seul problème avec votre approche est qu'il coule étroitement la logique commerciale et le stockage de la base de données. J'essaie toujours de trouver une solution pour moi moi-même ...
Qu'est-ce que j'ai essayé de faire était une mauvaise pratique. J'ai couplé mon entité et mes outils de DB de Zend comme @tivan Hušnjak mentionné.
Que devrait être fait est le couplage.
La logique commerciale doit être dans Services \ Controller et celles-ci devraient aborder l'entité et les méthodes.
Vous pouvez ajouter des fonctions d'assistance à l'entité doctrine que uniquement concerne les propriétés de l'entité.
En ce qui concerne mon objectif principal (d'avoir une classe d'entité que la doctrine CLI peut réécrire et mettre à jour):
La doctrine ne recherchent que des modifications des champs natifs \ Méthodes, met à la mises à jour en conséquence et jetez toutes les autres fonctions (aides). Donc, il n'y a pas de problème lorsque la doctrine mettez à jour l'entité PHP!
P.s.
Déplacer vers Symfony2.
«La logique des affaires devrait être dans Services \ Controller» - très mauvaise idée. La logique commerciale devrait être dans vos modèles autant que possible. Je ne peux pas comprendre quelle était votre raison de séparer des modèles et des entités. Pourquoi non seulement pour mettre votre logique commerciale dans des entités de doctrine qui (pour être honnêtement) sont vos modèles exactement.
@zeliboba Je suis d'accord, je suis d'accord avec la logique commerciale dans les contrôleurs est une mauvaise idée, c'est juste en désordre. En ce qui concerne les entités séparatrices et la logique commerciale, chaque ressource que j'ai rencontré des États que vous ne devriez pas ajouter une logique commerciale aux entités. Il est apparemment mauvais pour vos entités, surtout comme ils grandissent, mais je ne comprends pas pourquoi c'est le cas tbh.
OK, je vois plusieurs suggestions - essayer de faire quelque chose de similaire. Dans mon cas, un bon exemple serait que j'ai une entité utilisateur mappée en une à plusieurs avec une entité d'adresse. Certains champs sont similaires dans les deux mais ils ne sont pas vraiment des extensions les uns des autres - c'est-à-dire qu'ils partagent des champs «nom», numéro de téléphone, adresse électronique. Je voudrais une fonction de créer une nouvelle adresse pour un utilisateur donné qui pré-peuplera ces champs similaires (éventuellement être modifiés ultérieurement). Je vois des exemples ajoutant des fonctions comme celle-ci à l'entité aux modèles aux mappeurs. Quelles sont les meilleures pratiques?
Vous ne devez pas ajouter la logique commerciale aux entités, vous devez utiliser des modèles pour cela. Une façon de le faire serait:
En pratique, cela signifie que les modèles sont des classes PHP unis (ou peut-être une structure étendue en fonction de ce que vous utilisez), mais vos modèles n'ont aucun rapport avec votre base de données. Vos modèles font toutefois, instanciez vos référentiels de doctrine personnalisés 2. Par exemple. Un [1] http: / /docs.doctrine-project.org/fr/Latest/reference/working-with-Object.html#Custom-RePositories userpository peut contenir une méthode appelée getuserbyid . Dans vos référentiels est l'endroit où vous exécutez vos requêtes réelles et des instances d'entité de retour pour les modèles avec lesquels travailler.
Je n'ai que remarqué seulement, avez-vous vraiment votre appel à votre script pour modèle \ user ou est-ce juste une faute de frappe ici?