You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 :
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, iciGetByInstanceIdAndLocalIdAsync()
, 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.
The text was updated successfully, but these errors were encountered: