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...
Partager