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

QueryBuilder #29

Open
armetiz opened this issue Mar 28, 2013 · 0 comments
Open

QueryBuilder #29

armetiz opened this issue Mar 28, 2013 · 0 comments
Labels

Comments

@armetiz
Copy link
Contributor

armetiz commented Mar 28, 2013

L'objectif est de proposer une abstraction assez simple mais suffisante des solutions Orientées Graph. Et de permettre à ceux qui ne souhaitent pas s'équiper de serveur orientés graph d'avoir des fonctions basiques liées aux graphs sur des bases de données traditionnelles (MySQL, MongoDB).

Actuellement,
Nous avons un Manager qui sert de Facade et qui expose une API.
On se rends compte à l'usage que les filtres vont servir de "sac à ... foure tout".
De plus, la Facade va surement devoir s'allourdir avec le temps, et on risque d'avoir X méthodes getConnectionsXXX, countConnectionsXXX, etc... Outre une élégance réduite, ce n'est pas souple et ne permets pas des requêtes quelque peu complexe.

L'idée d'un QueryBuilder c'est de proposer une interface de communication avec l'utilisateur simple, souple et en respect avec la POO traditionnelle :p

Voici un exemple de syntaxe sur le QueryBuilder : https://gist.github.com/benjamindulau/d599bde751d548e0f7ba

Personnellement,
Je trouve que le QueryBuilder rends les choses sexy, et au delà de ca simplifier notre Facade.
C'est pas mal de boulot en plus alors qu'actuellement les choses fonctionne. Mais cela va nous permettre d'etre réellement plus évolutif, et de proposer une interface propre pour les requetes sur Graph.

PS : Pour rappel, nous ne souhaitons pas réaliser une abstraction complete et puissante des tout les systemes de graph. Mais simplement permettre au quidam d'avoir une solution de Graph pour "pas chere" et pouvant aller assez loin sur les requetes si besoin. Si l'utilisateur a besoin d'aller sur des choses ultra optimisés, performantes et complexes, il devra utiliser des solutions dédiés.

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

1 participant