Discussion :

[SergeF]

Bonjour,

je dois développer une appli Windows Forms, des Webservices et une base de donnée.

La question porte sur les choix des moyens d'accès à la BDD via les Webservices: actuellement, j'ai l'intention de créer une classe qui interfacera le client Forms aux webservices.

Cette classe permettra d'accèder aux données depuis le client Forms avec des méthodes conventionnelles (recordsets et ses méthodes/propriétés). Cette classe transformera donc mes requetes en requetes de type XML obtenant des réponses du webservice sous forme xml.

J'ai pourtant vaguement l'impression de réinventer la roue.

Si quelqu'un peut me donner, si cela existe, des infos sur des technologies que je pourrais mettre en oeuvre afin d'arriver à ce résultat, ce serait cool.
J'imagine que ce genre de service doit déjà exister au seing même de dotnet et/ou des technologies Microsoft.

Merci pour toute info.

[SaumonAgile]

Tu peux effectivement créer un Web Service sur un serveur avec toute la partie accès aux données.
Pour la partie client, il te faudra simplement "ajouter une référence web" en utilisant les outils de visual studio, cela va te générer un proxy côté client qui prendra en charge de manière transparente la sérialisation des objets pour les messages SOAP.

[SergeF]

Merci.

C'est bien ce que je fais. J'ai déjà créé un squelette de webservice. J'arrive à communiquer avec lui depuis mon appli Forms.

La question portait plus sur le contenu des messages SOAP ou leur utilisation.

Actuellement, ma requete est une string XML contenant le SQL et j'obtiens en réponse une string XML qui contient le resultat de ma requete sous forme structurée avec éventuellement des données connexes (record count, status)

L'étape suivante est de passer à une classe qui interfacera le client Forms aux webservices en lui permettant de travailler "comme" avec une BDD "normale".

En fait, j'ai l'impression que "tout le monde" a déjà du passer par là et même que Microsoft a du implémenter quelque chose dans le genre, d'ou ma question...

[SaumonAgile]

Le web service ne doit jamais prendre en paramètre du SQL, c'est une gigantesque faille de sécurité.
Ton web service doit contenir des méthodes du genre GetCustomers(...), GetInvoices(...), etc, et renvoyer des listes d'objets. Le web service fait ensuite appel à des classes qui vont se charger d'exécuter le SQL.

Par exemple (en C#), une méthode du web service :

Code :

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

1
2
3
4
5
[WebMethod]
public Client[] GetClients(CritereRecherche criteres)
{
    return ClientHelper.GetClients(criteres);
}

Le web service étant une couche de service (justement), il ne doit contenir aucun code fonctionnel.

La classe ClientHelper est située idéalement dans une assembly A différente, et les objets commun au web service et à l'assembly A seront quand à eux dans une autre assembly B (pour éviter d'éventuels problèmes de dépendances circulaires).

[SergeF]

Merci,

voilà, en quelques lignes des infos interessantes et assez évidentes après lecture. Une bonne piste pour démarrer.

Je comptais utiliser le webservice comme un bète serveur de données alors qu'il permet de faire bien plus ; et coté client d'utiliser des clients plus légers...

Si quelqu'un dispose d'un projet bien ficelé que je pourrais disséquer pour en apprendre plus, je suis preneur.

Bonsoir à tous.

[SaumonAgile]

Pour le projet d'exemple, je n'ai rien qui ne fusse pas soumis à la propriété intellectuelle de ma société, mais tu as l'idée générale, tu peux déja commencer par essayer de mettre ça sur papier, en définissant que la partie métier sera dans une assembly, que la partie interface dans une autre, que les objets communs seront dans une troisième et que le web service appellera le métier, et qu'il sera appelé par l'interface.

[SergeF]

Merci pour cette approche on ne peu plus structurée.

@++