Discussion :

[cyberpi]

Bonjour,

J'aimerais avoir votre avis sur les différentes manières de procéder à la réarchitecturation d'un système d'information. En voici les caractéristiques actuelles:

Serveur

• Serveur linux.
• BD Postgresql (200 tables) contenant de nombreuses procédures stockées et autres triggers. Son schéma a été consciencieusement défini au niveau conceptuel (dans un modèle Entité-Association étendu) avant d'être traduit en relationnel.
• Serveur web (apache) avec pages en php/Ajax attaquant directement la bd.
• Serveur de relai de messages pour les clients (voir plus loin) écrit en C# et tournant sous mono.

Client

• Client lourd, écrit en C# et tournant sur des machines Windows.
• Défini en 2 couches, une couche IHM attaquant une couche DAO encapsulant la base de données.
• Cette couche DAO a été construite en effectuant un mapping O/EA maison (et non pas OR) afin d'être le plus proche possible du schéma originel de la BD (en gros toutes les entités, mais pas les associations sans attributs, sont représentées par des classes C# dans le client), dispose d'un pool de connexions sur la BD, d'un cache d'objets (qui en garantit l'unicité) et d'un cache de requêtes.
• Lors de la mise à jour, de la création ou de la suppression d'un objet, un message est envoyé au serveur afin qu'il puisse en informer les autres clients.

Les défauts du système

• Au départ la partie web et la partie client C# étaient fortement découplées et une modification de l'un n'entraînait pas de répercussion sur les données de l'autre (dit autrement, chacun s'occupait d'une partie de la bd).
  Maintenant la situation est différente et une modification dans le web peut avoir une influence sur les données manipulées par un client. Il faut donc pouvoir l'avertir que le contenu de telle table a été modifiée.
• Le client est lourd. Malgré de nombreuses optimisations que ce soit au niveau des requêtes (de plus en plus de logique métier a migré directement dans la BD) ou au niveau des caches, il n'en reste pas moins vrai que pour construire des objets au niveau du client, il faut émettre une requête SQL sur le serveur et récupérer les résultats à travers le réseau. Selon le nombre d'objets nécessaires à la visualisation d'une IHM donnée, cela peut être lent et parfois, trop lent...

La situation n'est pas critique et les applications fonctionnent bien (lire: les utilisateurs ne se plaignent pas) mais, à terme, je crois que les deux points ci-dessus vont réellement poser problème.

Il est clair que je désire conserver la base de données telle quelle. C'est, à mon avis, le point fort du système qui permet des requêtes complexes à faible coût. Par contre, pour le reste, je suis ouvert à toute suggestion, même radicale...

[*alexandre*]

Qu'es-ce qui est coûteux en terme de temps la mise à jour du cache ? Ou la visualisation des données ?

[cyberpi]

Qu'es-ce qui est coûteux en terme de temps la mise à jour du cache ? Ou la visualisation des données ?

Une fois que les objets sont présents sur le client, leur visualisation ne prend pas plus de temps que pour une application non client-serveur. Par contre, rapatrier les objets peut être coûteux.

Prenons un exemple.

Imaginons qu'on ait des personnes qui possèdent des voitures et que chaque voiture appartienne à une personne au maximum. Maintenant, dans une interface on voudrait afficher pour chaque personne qui possède une voiture les numéros de plaque de ses voitures. Style, "Doe: XYZ ABC".

Pour ce faire on aimerait écrire quelque chose du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
LinkedList<Person> persons = Person.GetAllOwner();
foreach (Person p in persons) 
{
  Console.Write(p.Name + ": ");
  foreach (Car c in p.GetCars())
     Console.Write(c.Number + " ");
  Console.WriteLine();
}

Pour ce faire, N+1 requêtes SQL vont partir sur le serveur:
1. Pour récupérer les N propriétaires de voitures.
N. Pour récupérer les voitures de tous les propriétaires.

Même si on a déjà dans le cache quelques voitures et personnes, les requêtes vont être émises telles quelles sur le serveur. C'est seulement lors de la construction des objets résultat qu'on vérifie que pour chacun des objets à construire qu'on ne les a pas déjà dans le cache. Pourquoi? Parce que sinon il faut a) transformer automatiquement la requête SQL pour exclure les objets déjà présents (rajouter une clause: where id not in (25, 34, 48, ...)) et b) effectuer la même requête dans le cache pour les objets présents (traduire du SQL en C# étant tout sauf trivial).

Par ailleurs, les objets sont construits complètement. Même si au final on a besoin que deux attributs (le nom et le n° de plaque), tous les autres attributs des personnes vont transiter par le réseau (et l'encombrer). On pourrait charger seulement les valeurs des attributs à la demande, mais cela multiplierait les requêtes...

[*alexandre*]

Rien à voir avec le sujet mais il ne faut jamais déclarer du code comme vous le faites : LinkedList<Person> persons = Person.GetAllOwner();
devrait plutot devenir List<Person> (je sais pas si vous avez l'équivalent de checkstyle sous .net ...)

Mais pour revenir à ton cas les systèmes de cache évolués savent non seulement mettre en cache des données mais également des requêtes je ne sais pas ce que tu utilises comme cache ...

Mais je dois probablement mal comprendre ton problème car si tu utilises linq tes objets seront charger peut importe que tu veuilles accéder à l attribut x ou y

[cyberpi]

Rien à voir avec le sujet mais il ne faut jamais déclarer du code comme vous le faites : LinkedList<Person> persons = Person.GetAllOwner();
devrait plutot devenir List<Person> (je sais pas si vous avez l'équivalent de checkstyle sous .net ...)

Sauf si on veut utiliser des méthodes propres à la LinkedList qui n'existent pas dans l'interface List... Mais c'est vrai que dans mon exemple vite fait, c'est inutile...

Mais pour revenir à ton cas les systèmes de cache évolués savent non seulement mettre en cache des données mais également des requêtes je ne sais pas ce que tu utilises comme cache ...

J'utilise un cache fait maison qui cache objets et requêtes. Mais je ne pense pas que ça changerait grand chose avec un cache évolué à moins qu'il puisse dire quelles requêtes ont été invalidées par un update d'un autre client. Le mien est brutal et invalide tout le cache de requêtes (pas celui d'objet) dès qu'une modification a eu lieu dans la bd. A quels caches penses-tu?

Mais je dois probablement mal comprendre ton problème car si tu utilises linq tes objets seront charger peut importe que tu veuilles accéder à l attribut x ou y

Je n'utilise pas linq (je devrais?) mais des bonnes vieilles requêtes SQL. Est-ce que linq a le même pouvoir d'expressivité que le SQL?

Mon problème est double:
- Minimiser le trafic sur le réseau.
- Pouvoir informer les clients lourds que le web a modifié la base.

[*alexandre*]

Sauf si on veut utiliser des méthodes propres à la LinkedList qui n'existent pas dans l'interface List... Mais c'est vrai que dans mon exemple vite fait, c'est inutile...


J'utilise un cache fait maison qui cache objets et requêtes. Mais je ne pense pas que ça changerait grand chose avec un cache évolué à moins qu'il puisse dire quelles requêtes ont été invalidées par un update d'un autre client. Le mien est brutal et invalide tout le cache de requêtes (pas celui d'objet) dès qu'une modification a eu lieu dans la bd. A quels caches penses-tu?


Je n'utilise pas linq (je devrais?) mais des bonnes vieilles requêtes SQL. Est-ce que linq a le même pouvoir d'expressivité que le SQL?

Mon problème est double:
- Minimiser le trafic sur le réseau.
- Pouvoir informer les clients lourds que le web a modifié la base.

Oui tu peux tout faire avec Linq, en fait je pense que tu pourrais contourner le problème en forçant le rafraichissement de ton client lourd à l'aide d'un timer et ton cache ne loaderait que les données dont la version à changer

[cyberpi]

Oui tu peux tout faire avec Linq, en fait je pense que tu pourrais contourner le problème en forçant le rafraichissement de ton client lourd à l'aide d'un timer et ton cache ne loaderait que les données dont la version à changer

Merci de tes conseils, mais je ne suis pas certain que ta proposition résolve tous mes soucis... En particulier:
- D'après ce que j'ai lu linq est nettement plus lent que du SQL pur et dur et est supplanté par le framework Entity (OR/M) que MS a mis en place.
- Comment, en utilisant linq, je résoudrais le fait que mon serveur web veuille avertir les clients lourds que quelque chose a été modifié dans la base?