QueryObject et méthodes de recherches

[Clément]

Bonjour,

On (sur le web et sur cette liste) a parlé il y a quelques mois du
problème de la multiplication des méthodes de recherche comme décrit
sur le blog d'Ayende : http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singleton.aspx.
Une des solutions est de créer des QueryObject. C'est la solution que
nous implémentons mais en ajoutant quelques subtilités et c'est là que
j'ai des questions.

1) Nous avons fait des QueryObject de 2 types, soit simples pour gérer
les DateTime, Integer, soit composites pour décomposer des recherches
un peu complexes (comme sur la ligne métier du client des informations
à retourner, i.e recherche sur Information.Client.BusinessLine...),
pour effectuer une requête, on a donc un code du genre :

InformationQueryObject info = new InformationQueryObject(); // inherit
from CompositeQueryObject
info.Client = new ClientQueryObject(); // inherit from
CompositeQueryObject
info.Client.BusinessLine = new BusinessLineQueryObject(); // inherit
from CompositeQueryObject
info.Client.BusinessLine.Id = "12"; // value that come from a
DropDownList.Value for example, converted by BusinessLineQueryObject
into an IntegerQueryObject, which is added to the collection of
component of the composite
ApplicationService.Search(info);

Je suis un peu géné par ce code, mais je ne sais pas trop l'expliquer
comme ça...n'auriez-vous pas des commentaires à faire ?

2) On souhaitait supprimer la corrélation entre les valeurs
particulières gérées dans les listes déroulantes du site et les
filtres appliqués en base, ainsi que la complexité conditionnelle
induite au niveau de l'accès, on a utilisé des SpecialCase des
QueryObject afin de gérer ces cas particuliers, combiné à
l'utilisation du container IoC. Par exemple, on a la classe de base
BusinessLineQueryObject et un SpecialCase AnyBusinessLineQueryObject
(qui hérite de BusinessLineQueryObject pour surcharger le
comportement), la première applique le filtre sur la ligne métier,
alors que le SpecialCase n'applique aucun filtre. On doit donc
instancier la bonne classe en fonction de la valeur sélectionnée dans
la liste déroulante correspondante, ce que nous déléguons à une classe
encapsulant le container IoC (AbstractFactory). Cela donne un code du
genre :

InformationQueryObject info =
AbstractFactory.GetInstance<InformationQueryObject>();
info.Client = AbstractFactory.GetInstance<ClientQueryObject>();
info.Client.BusinessLine =
AbstractFactory.GetInstance<BusinessLineQueryObject>
(dropDownListValue); // if dropDownListValue is "Any", returns an
instance of AnyBusinessLineQueryObject, else returns
BusinessLineQueryObject
info.Client.BusinessLine.Id = dropDownListValue;
ApplicationService.Search(info);

La question ici est de savoir comment faire pour s'abstenir de faire
appel au container IoC (via AbstractFactory, sachant que la méthode
GetInstance<T>(string value) se contente d'appeller Resolve<T>(string
name)) ? Je pense notamment au cas où on utiliserait les ModelBinder
d'un site en MVC, serait-il possible de laisser le ModelBinder faire
cet appel ?

Clément

[Gauthier Segay]

Bonjour Clément,

pour 1, ce qui me gène c'est le fait de devoir instancier manuellement
des propriétés d'un objet query, ce n'est pas du tout fluent et
encapsulé à mes yeux et tu vas répéter ce code aux différents endroits
ou tu veux exécuter une requête paramétrée de ce type. La raison est-
elle que tu utilises des classes spécialisées (avec du polymorphisme)?

Après sans savoir ou ce situe le code (peut être à un seul endroit
dans l'application) ni comment est implémenté le service (que fait-il
du query object pour parvenir au résultat et comment c'est fait) je ne
me permettrait pas de dire que le code n'est pas bon.

pour 2, la abstract factory me semble overkill, tu dois maintenant
tester que le container/abstract factory implémente bien la logique
etc; avoir une classe pour le any et une classe pour le single value,
et une classe pour le multiple value semble une bonne abstraction mais
en terme d'API cela ne me donne pas trop envie (pas assez encapsulé,
besoin réél de factory)

j'avais laissé un commentaire sur le post suivant qui peut
éventuellement répondre:

http://ayende.com/Blog/archive/2009/04/18/the-dal-should-go-all-the-way-to-ui.aspx#30352

suite à quoi Olivier Duval avait posé une question ici sur les
manières de préparer les requêtes paramétrées, je lui avait fourni un
exemple issu du même moule que mon commentaire, je suppose qu'il en à
fait un truc vachement mieux depuis ;)

En général j'essaye d'encapsuler cette logique dans une seule classe
(criteria builder), mais je n'ai pas eu à traiter une UI avec 1593
paramètres optionnels comme il semble être le cas ici (en supposant
qu'il ne s'agit que d'une partie du query object)

Je laisse aux autres le soin de dire des choses plus intelligentes
plus constructives...

On Sep 14, 4:40 pm, Clément <clement.bouill...@gmail.com> wrote:
> Bonjour,
>
> On (sur le web et sur cette liste) a parlé il y a quelques mois du
> problème de la multiplication des méthodes de recherche comme décrit

> sur le blog d'Ayende :http://ayende.com/Blog/archive/2009/04/17/repository-is-the-new-singl....