Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Utilisation d'un Listener ou du Manager pour remplir Model/Connection #8

Closed
armetiz opened this issue Feb 6, 2013 · 6 comments
Closed
Labels

Comments

@armetiz
Copy link
Contributor

armetiz commented Feb 6, 2013

Doit-on charger automatiquement les Connection::source & destination de maniere automatique via un Listener Doctrine ?
Dans ce cas, il en faut un pour ORM, ODM etc..

@choomz
Copy link
Member

choomz commented Feb 6, 2013

Je pense qu'il faut gérer les deux ORM / ODM, c'est une couche en plus certes, mais si on part dans la navigation de type graph en excluant mongo dès le départ, ça risque d'être frustrant.

D'autant plus que Doctrine le gère (et oui nous serions couplé à doctrine).

@armetiz
Copy link
Contributor Author

armetiz commented Feb 7, 2013

Yes exactement. Mais surtout, je pense qu'il faut pouvoir gérer aussi des solutions plus adaptées : Neo4J.

D'ailleurs, est-ce que l'on doit pouvoir faire une Connection entre un model User géré via RDBMS, et un Book géré via NoSQL ? QUID MongoDB, CouchDB & surtout Neo4J.

@choomz
Copy link
Member

choomz commented Feb 7, 2013

Je pense que pour une v1, il ne faut pas s'arracher les cheveux avec de la compatibilité inter système.
Par contre une implémentation du pattern adapter avec au démarage Interface + adapter doctrine orm + doctrine odm mongo db me semble nécessaire.

Pour ce qui est de Neo4J, même si en terme de modelisation c'est le plus adapté rapport au bundle, je ne suis pas sur que la gestion des connections se fasse avec notre approche ... si quelqu'un pouvait confirmer ou infirmer ?

@benjamindulau
Copy link
Member

Je trouve que l'utilisation du Listener n'est pas trop approprié.
IMHO, c'est le repository, puisque que c'est lui l'implementation concrète du système de persistance, qui devrait transformer l'objet avant de le retourner.

On aura donc une interface pour le repo, et une seule classe à implémenter pour chaque système de persistance, ORM, ODM, propel, ou autre.

@armetiz
Copy link
Contributor Author

armetiz commented Feb 7, 2013

Dans ce cas, cela signifie que l'on ne peux lier que des objets appartenant au meme système de persistance.
Car un Repository est lié à système.. Si c'est lui qui gere la transformation de la Connection, il ne va pouvoir récupérer des objets appartenant uniquement au meme système.

De mon coté, je ne pense pas avoir besoin d'utiliser un RDBMS + un NoSQL pour stocker mes Models..

Il peut-être interessant de définir le besoin pour répondre à la question.

PS : Je pense que le Listener est en effet inapproprié. Par contre, je pense que cela doit être initié par le Manager et non par le Repository qui gere la Connection.

@armetiz
Copy link
Contributor Author

armetiz commented Feb 26, 2013

Actuellement c'est le Repository qui est en charge de remplir les Connection.

@armetiz armetiz closed this as completed Feb 26, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants