Discussion :

[SkYsO]

Salut à tous,

En ce moment j'ai une application qui n'est pas en 3 tiers. Hors dans certain cas et surtout sur des sites distants c'est très long. Il y a de gros traitements avec une base de données et pas mal de trafic réseau.

J'aimerai pouvoir faire du vrai client/serveur avec une partie installée sur le poste client et une autre sur le serveur qui fera les interrogations BDD et qui renverra quelque chose au client.

Mais justement quoi renvoyer ????
J'utilise pas mal d'objet (dérivant du TObject) pour ensuite les traiter et afficher différentes chose.

Hors je me demandais si on pouvais faire pareil en architecture 3 tiers ? Peut-on transmettre des objets ? ou dois-je trouver autre chose, comme par exemple un fichier Xml que le client récupère et retransforme de son côté en objet.
Que faire ??

Merci pour votre aide

++

[Tardiff Jean-François]

Bonjour,

Ce que l'on appelle généralement du Client/Serveur est l'attaque par un client d'une base de donnée basée sur un serveur.
Le serveur peut être le client, bien qu'il soit, en générale, une autre machine.
Ce sont les information de la (ou des) base de donnée qui circule entre le client et le serveur.
Pour limité le nombre d'information circulant sur le réseau (optimisation temps de réponse), il faut veillez à ne demander que les informations nécessaire et, si possible, à ne les demander qu'une seule fois.

Un objet n'est pas stocké dans une base de donnée et ne peut donc pas être "renvoyer" par la base. Par contre vous pouvez stoker les informations relative à un objet et le créer, en l'initialisant en utilisant les dites données.

Les affichage se font en générale avec des composants spécialisés qui se connecte directement au datasource.
Exemple :
TDBEdit, équivalent au TEdit pour les base de donnée
TDBStringGrille équivalent au TStringGrid pour les base de données

Si vous avez des composants spécialisé pour affiché vos données, vous pouvez en dériver une version pour un affichage à partir d'une base de donnée, ou utiliser les événements du datasource pour les renseigner lorsque les données changes.

[SkYsO]

Bonjour et merci pour cette réponse.

C'est actuellement ce que je fais. Mes composants ADO bossent avec la base de données. Hors j'aimerai maintenant passer par des Sockets. Donc la connection entre mon client et mon serveur se fera par des sockets et mon Serveur qui sera sur la même machine que mon serveur sql fera les requêtes quand le client lui donnera une commande spécifique.

En fait ce que je veux savoir, c'est dans le cas des sockets, que puis-je faire transiter ? des fichiers ? des objets ? des lignes de textes ?

[Tardiff Jean-François]

Je pense que vous voulez parler de 3 tiers.


Une Application cliente (1° tier) se connecte à une application maitre (2° tier) qui peut être sur le même ordinateur ou sur un autre.

L'application maitre (2° tier) gère les connections avec la source de donnée (3° tier) qui est en générale une base de donné.

Si c'est cela je ne peut pas tellement vous aider, car je n'y connais pas grand chose.
Je peux juste vous donner quelques généralités.

Ce n'est pas du client/Serveur, c'est du 3 tiers.
Suivant les types de liaison que vous utilisé, vous pouvez Transmettre ou non des objets (par exemple, je crois que c'est possible en Corba).
Suivant le type de liaison utilisé, le Serveur peut ou ne peut pas initier une demande avec le client. (C'est important car si le serveur peut toujours initier la conversation, les système de type internet interdisse au serveur de le faire. Si vous désirer ouvrir votre application a plusieurs type de communication, il vous faudra donc utiliser le système le plus contraignant et faire en sorte que seul le client "pose des questions" au serveur. En pratique cela veut dire que si une information change, le serveur ne vas pas contacter les client pour le signaler. Ce sont les clients qui toutes les .. minutes vont demander au serveur si les informations sont modifiés).

Désolé, je ne m'y connais pas tellement plus et ne peut pas vous apprendre autre chose.

[SkYsO]

merci encore

et effectivement c'est bien 3 tiers. Je vais changer mon post initial

[Rayek]

Je ne pense pas que tu gagneras vraiment beaucoup en passant d'un client/serveur à une structure 3 Tiers. Les temps seront peut être beaucoup plus long en utilisant du 3 tiers (vu que tu rajoute encore une couche Client -> Serveur -> Serveur Base de données -> Serveur -> Client ) par rapport au Client/serveur classique (Client -> Serveur base de données -> Client)
De plus, ca t'obligera à maintenir 2 programmes au lieu d'un seul et il te faut completement créer un système de dialogue entre le client et le serveur.

Je pense que le mieux reste à optimiser l'existant (Requete optimisé, utilisation de TClientDataset pour certaine table, etc ...)

[SkYsO]

Le problème aussi pour le moment c'est mon application est "posée" sur un partage. Et dans certains cas elle peut être exécutée par des personnes qui sont sur des sites distants donc pas physiquement au même endroit donc réseau plus complexe. Et là mon application par en brioche. Temps de réponses catastrophiques.

Est ce que le N tiers ne pourrait il pas sauver ça ? car communication plus uniformes malgré le changement de localisation des clients ?

[Tardiff Jean-François]

Ne serait il pas possible de revoire vos requêtes pour minimiser le trafic réseau ?

[SkYsO]

a priori c'est déjà fait mais bon il se peut qu'elles soient encore perfectible.
Le soucis aussi le situe au niveau des échanges qui sont trop nombreux aussi. Si on passe par une application N tiers il ya aura beaucoup moins de communications entre le client et le serveur que entre le serveur et la base car :
le client envoi sa demande, le serveur reçoit et fait tout un tas de calcul, cherche plusieurs données et au final ne renvoi qu'une chose au client.

Mais sous quel forme ? un fichier ? on peut transmettre une ObjectList d'objet ? (je n'ai pas l'impression) avec des sockets

[Tardiff Jean-François]

Il est toujours possible de transmettre un Fichier binaire. Donc une streamliste, contenant une liste de quelque chose. L'objet peut être pas mais la sauvegarde en steam liste oui. Par contre le développement risque d'être long si vous débuter en n tiers.

[Rayek]

a priori c'est déjà fait mais bon il se peut qu'elles soient encore perfectible.
Le soucis aussi le situe au niveau des échanges qui sont trop nombreux aussi. Si on passe par une application N tiers il ya aura beaucoup moins de communications entre le client et le serveur que entre le serveur et la base car :
le client envoi sa demande, le serveur reçoit et fait tout un tas de calcul, cherche plusieurs données et au final ne renvoi qu'une chose au client.

Mais sous quel forme ? un fichier ? on peut transmettre une ObjectList d'objet ? (je n'ai pas l'impression) avec des sockets

Pas sur que le transfert perso x Tiers soit mieux optimisé pour éviter une surcharge (un bon nombre de personnes ont travaillé sur les dialogues client/serveur de la base de données, je doute qu'il soit possible de faire beaucoup mieux)

Je pense qu'il faudrait peut être revoir l'architecture du logiciel à la base et revoir les requetes (pas de requete "select *", utiliser des vrais jointures "inner join")
Ou alors il faudrait peut être revoir le type de base de données (quel est il d'ailleur ? oracle ? SQL Server ? MySQL ?)
Sinon l'hébergement peut jouer (une connexion 512 sera moins performante qu'une 1024 )

[SkYsO]

Pour le moment mes requêtes utilisées dans des TADOQuery sont, je pense, bien formée.

Pas de Select *, que des INNER JOIN sur le moins de table possible. J'ai peut être encore du boulot là dessus.

[Tardiff Jean-François]

A mon avis se n'est pas une question de jointure. Si c'était le cas SkYsO aurait le problème dans tous les cas, y compris en mode local.

Ce doit être la quantité de donné transitant.

2ventuellment des vues pourrait être utile en retournant des données déjà pré- assemblé. Mais concevoir des requête limitant le nombre de donné retourner n'est pas toujours possible.
Autrement regarder ces liens :
http://www.drbob42.com/pdf/corba_delphi.pdf
http://corba.developpez.com/faq/
http://www.drbob42.com/pdf/corba_delphi.pdf

Ils pourront peut être vous aider.

[Rayek]

A mon avis se n'est pas une question de jointure. Si c'était le cas SkYsO aurait le problème dans tous les cas, y compris en mode local.

Je n'ai jamais dit le contraire, on ne connait pas l'application de Skyso et on ne sait même pas la base de données qu'il utilise, alors on ne peut faire que des suppositions

Ce doit être la quantité de donné transitant.

Oui, tout à fait (pour cette raison que je parle aussi de l'hébergement)
Après il est clair qu'un filtrage plus précis des données serait un mieux pour retourner un nombre d'enregistrement moindre.

@ Skyso :

Quel est le type de la base de données ? Oracle/SQL Serveur/autres ?
Combien d'enregistrements retournent les requetes ?

[SkYsO]

Salut,

et bien je bosse sur du SQLServer. Mon nombre d'enregistrement est assez relatif. Mais bon c'est pas encore de l'ordre du millier.

[themei]

Bonjour,

Ce que l'on appelle généralement du Client/Serveur est l'attaque par un client d'une base de donnée basée sur un serveur.
Le serveur peut être le client, bien qu'il soit, en générale, une autre machine.
Ce sont les information de la (ou des) base de donnée qui circule entre le client et le serveur.
Pour limité le nombre d'information circulant sur le réseau (optimisation temps de réponse), il faut veillez à ne demander que les informations nécessaire et, si possible, à ne les demander qu'une seule fois.

Un objet n'est pas stocké dans une base de donnée et ne peut donc pas être "renvoyer" par la base. Par contre vous pouvez stoker les informations relative à un objet et le créer, en l'initialisant en utilisant les dites données.

Les affichage se font en générale avec des composants spécialisés qui se connecte directement au datasource.
Exemple :
TDBEdit, équivalent au TEdit pour les base de donnée
TDBStringGrille équivalent au TStringGrid pour les base de données

Si vous avez des composants spécialisé pour affiché vos données, vous pouvez en dériver une version pour un affichage à partir d'une base de donnée, ou utiliser les événements du datasource pour les renseigner lorsque les données changes.

Un objet peut etre stocker dans un BDD !!!
Il y a des SGBD Objet et des SGBD Objet-Relationnel (Oracle par exemple).

Apres il y a des gestionnaire de persistance évolué qui existent, qui permette de ne pas s'occuper de la partie relationnelle.

Sinon le 3-tiers ne resous pas les pbs de performance réseau magiquement non plus. :'(

[themei]

Pas sur que le transfert perso x Tiers soit mieux optimisé pour éviter une surcharge (un bon nombre de personnes ont travaillé sur les dialogues client/serveur de la base de données, je doute qu'il soit possible de faire beaucoup mieux)

Je pense qu'il faudrait peut être revoir l'architecture du logiciel à la base et revoir les requetes (pas de requete "select *", utiliser des vrais jointures "inner join")
Ou alors il faudrait peut être revoir le type de base de données (quel est il d'ailleur ? oracle ? SQL Server ? MySQL ?)
Sinon l'hébergement peut jouer (une connexion 512 sera moins performante qu'une 1024 )

Un n-Tiers bien concu, les echanges BDD<->Serveur d'application seront rapides car le SGBD et le Serveur d'application sont proche (idealement meme dans le meme reseau).

Dans son cas, chaque client interroge la BDD, et donc s'ils faut 5 requete pour charger l'objet, ca prendra plus de trafic les 5 requete, que de transferer l'objet completement chargé.

En principe en n-Tiers, si le tiers de presentation est de l'applicatif lourd, seul les instances d'objet sont transferées et passe donc par le lien reseau entre le serveur d'application et la couche de présentation. Ca represente moins de données. De plus si c'est long au debut, plus l'applicatif ira vite car il a ses instances deja chargées et en cache, et donc les requete BDD finissent par etre que des update et sont géré de maniere asynchrone.

EDIT : Donc on soulage le SGBD, mais le réseau sera pas forcement beaucoup plus rapide, mais on gagne quand meme un peu puisque si on a des requete un peu lourde pour le chargement des objet, si on les faits le moins possible globalement ça ira plus vite.

[Rayek]

Pour les sites distants, comment se connectent ils à la base de données ?
Par internet ?
Par Intranet ?
Autres ?

Tu parles de temps de réponse long, c'est environ combien ce long ?

[SkYsO]

Un n-Tiers bien concu, les echanges BDD<->Serveur d'application seront rapides car le SGBD et le Serveur d'application sont proche (idealement meme dans le meme reseau).

Dans son cas, chaque client interroge la BDD, et donc s'ils faut 5 requete pour charger l'objet, ca prendra plus de trafic les 5 requete, que de transferer l'objet completement chargé.

En principe en n-Tiers, si le tiers de presentation est de l'applicatif lourd, seul les instances d'objet sont transferées et passe donc par le lien reseau entre le serveur d'application et la couche de présentation. Ca represente moins de données. De plus si c'est long au debut, plus l'applicatif ira vite car il a ses instances deja chargées et en cache, et donc les requete BDD finissent par etre que des update et sont géré de maniere asynchrone.

EDIT : Donc on soulage le SGBD, mais le réseau sera pas forcement beaucoup plus rapide, mais on gagne quand meme un peu puisque si on a des requete un peu lourde pour le chargement des objet, si on les faits le moins possible globalement ça ira plus vite.

Voilà c'est cette solution que je voulais aborder. Mais mon soucis est de savoir quoi transmettre ensuite : peut-on créer des objets et les transmettre directement par le réseau ?

[edam]

ma petit contribution