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

Ségrégation de la Query #260

Open
nfaugout-lucca opened this issue Oct 25, 2018 · 0 comments
Open

Ségrégation de la Query #260

nfaugout-lucca opened this issue Oct 25, 2018 · 0 comments

Comments

@nfaugout-lucca
Copy link
Contributor

Toujours après une discussion avec Raph, on semble aligné sur le fait d'essayer de couper l'objet Query en 2 parties bien distinctes :

  • une partie à destination du Domain, et qui porte des informations utiles au Domain pour prendre des décisions
  • une partie à destination de l'Infra (plus précisément des Repos), et qui correspond à la transposition en C# des différents éléments de la query web (fields, filtres, ..)

En effet, je suis parti du constat que la plupart du temps, le Domain fait office de passe-plat entre la couche Web et la couche Infra concernant la Query. Du coup on est actuellement obligé de définir la Query dans le Domain, et ceci peut entraîner des mauvaises pratiques.

Ce commit met en évidence le problème, on est dans une Collection et qui interroge le Repo avec une Query qu'on fabrique sur place. La Query devrait être réservée à un usage générique quand la requête HTTP arrive du Web et donc est imprévisible, càd qu'on ne sait pas dans quel contexte l'appelant fait cette requête. Ici on est dans un contexte connu, la méthode GetByMobileTokenAsync() et donc on peut appeler une méthode explicite du Repo, ici GetByInstanceIdAndLocalIdAsync(), qui pourra, si elle le désire, utiliser une Query générique ou pas.

NB : mon exemple n'est pas tout à fait bon car en l'occurrence la méthode du Repo n'utilise pas de Query générique, ce qui peut poser des pb : les includes sont oubliés, ainsi que les droits. Mais ça ne remet pas en cause la proposition.

En résumé, Query ne devrait être utilisé QUE dans le cas générique, et donc tous les cas explicites présent dans le code C# ne devrait jamais utiliser Query, sauf au sein d'une méthode explicite du Repo. Donc Query ne devrait finalement être utilisé QUE depuis Web ou dans l'Infra, jamais dans le Domain.

Pour arriver à créer une Query, et la passer à l'Infra sans avoir besoin de la référencer depuis le Domain, il existe une technique, qu'on utilise déjà pour le IPrincipal, et qui consiste à utiliser l'injection. Le Web fabrique la Query et la set au niveau d'un provider. Le Repo s'injecte le provider pour récupérer la query.

La Query devient alors "ambiante", on peut se l'injecter d'où on veut. Ca peut paraître dangereux, mais en réalité pour 1 requête HTTP donnée, il n'existe en tout et pour tout qu'une seule Query générique.

En effet, une fois arrivé sur le controller web et la Query fabriquée, tous les appels de code internes sont explicites, et donc utilisent leur propres paramètres pour décrire le besoin. Ce besoin peut éventuellement être encapsuler dans ce qu'on pourrait appeler une query du Domain (la partie de Query qui resterait dans le Domain), mais ça n'est pas obligatoire.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant