Discussion :

[max_25]

Bonjour à tous,

Dans le but de migrer une appli de WinForms vers WinRT je me pose des questions sur l'accès aux données depuis une interface WinRT, principalement pour quantifier le code qu'il y aura à réécrire.

Ce que je sais pour le moment c'est que l'on ne peut accéder à une base de données distante qu'à partir d'un service web. Déjà est-ce toujours d'actualité ?
De plus comment s'échange les données entre le service et l'application ? Prenons un exemple simple : je souhaite accéder à la liste de tous mes clients, j'ai pour ça une classe métier 'Client'.
Je vais donc devoir développer un service WPF qui lui me retourne une liste de Client ? de tous mes clients ? mais si par exemple j'ai une quantité énorme de donnée et que je ne veux que les clients français ? Je ne vais quand même pas retourner tous mes clients puis filtrer les français dans l'appli cliente.

Pour le moment dans mon appli j'ai une classe donnée par classe métier (ClientDB pour notre exemple) qui contient les requêtes SQL me retournant les objets ou les listes d'objets dont j'ai besoin. Ces classes sont perdues ok ! mais je me demande donc si je pourrai récupérer mes classes métiers. Par exemple dans Client j'ai une méthode static (qui contient le SQL) qui me retourne un client à partir de son numéro de client, une autre qui me retourne une liste de client à partir d'un code postal ...ect. Comment peut on faire ce genre de choses avec WinRT ? Est-ce que je peux faire un service qui exécute une requête que je lui donne et me retourne une liste ... d'Object ? d'un Type que je lui donne ? N'ayant plus accès à System.Data je ne peux pas recevoir de DataTable que vais-je recevoir ?

Bref c'est confu (en tout cas pour moi) et je ne trouve pas d'exemple sur le net.

Je vous remercie d'avance, et n'hésitez pas si vous voulez plus de précision sur ma demande qui est, après relecture, assez confuse ... mais qui illustre assez bien mon état d'esprit concernant WinRT .

Bonne journée.

[Invité]

Ce que je sais pour le moment c'est que l'on ne peut accéder à une base de données distante qu'à partir d'un service web. Déjà est-ce toujours d'actualité ?

Oui, avec une application Modern UI tu es obligé de passer par un service web pour accéder à la base de données distante.

De plus comment s'échange les données entre le service et l'application ? Prenons un exemple simple : je souhaite accéder à la liste de tous mes clients, j'ai pour ça une classe métier 'Client'.
Je vais donc devoir développer un service WPF qui lui me retourne une liste de Client ? de tous mes clients ? mais si par exemple j'ai une quantité énorme de donnée et que je ne veux que les clients français ? Je ne vais quand même pas retourner tous mes clients puis filtrer les français dans l'appli cliente.

On parle de service WCF et pas WPF
Tu sais un service ça expose des opérations et une opération est tout simplement une méthode comme tu en créerais dans une application console et elle peut avoir zéro ou plusieurs paramètres. Si tu veux tous les clients alors tu crées une opération GetClustomers sans paramètres. Si tu veux une liste de clients suivants un ou des critères alors tu les passes ces critères en tant que paramètres de ton opération comme par exemple GetClustomersByCity(string cityName).

Pour le moment dans mon appli j'ai une classe donnée par classe métier (ClientDB pour notre exemple) qui contient les requêtes SQL me retournant les objets ou les listes d'objets dont j'ai besoin. Ces classes sont perdues ok ! mais je me demande donc si je pourrai récupérer mes classes métiers. Par exemple dans Client j'ai une méthode static (qui contient le SQL) qui me retourne un client à partir de son numéro de client, une autre qui me retourne une liste de client à partir d'un code postal ...ect. Comment peut on faire ce genre de choses avec WinRT ? Est-ce que je peux faire un service qui exécute une requête que je lui donne et me retourne une liste ... d'Object ? d'un Type que je lui donne ? N'ayant plus accès à System.Data je ne peux pas recevoir de DataTable que vais-je recevoir ?

Si ton application comporte déjà des couches ! Alors moi je te dis que la couche DAL et la couche métier ne sont pas perdues. Tu les laisses telles quelles sans rien changer du tout. Ce que tu as à faire c'est créer des classes DTO (Data Transfert Object) et c'est ces classes qui seront l'intermédiaire entre ton service et tes différents classes et c'est aussi elles qui seront exposées à l’application Modern UI.

[GuruuMeditation]

Pour la DB, tu peux utiliser SQLite : http://www.guruumeditation.net/blog/...-windows-store

Pour les services WCF, rien ne n'empêche d'avoir un paramètre, par exemple, qui donne le nom du pays pour lequel il faut renvoyer les clients.

[Invité]

Pour la DB, tu peux utiliser SQLite : http://www.guruumeditation.net/blog/...-windows-store

Peut-être que je me trompe mais il parle d'une base de données distante. Alors je ne pense pas qu'il veuille tout passer en locale s'il s'oriente vers SQL Lite

[max_25]

Bonsoir et merci pour vos réponses.

En effet je parle d’accès distant donc rien en local, SQLite n'est pas une solution pour mon cas.

h2s84 je comprends que mon service peut m'exposer plusieurs méthodes avec ou sans paramètres. Mais cela m'impose de modifier mon service (ajout de méthode) dès que mon appli cliente évolue et me demande d'autres infos. Apparemment un développement en parallèle s'impose donc.
Je suis de nature assez féniant (paraîtrait que c'est une qualité chez les développeurs ) je me vois bien faire un service avec une méthode GetData(string sql) ou sql serait ma requête et hop le service me retourne mes données ... mais j'ai l'impression que vous allez me contredire, par exemple sur le type de retour...
D'ailleurs pour l'exemple que tu me donne h2s84, GetCustomers(), cette méthode me retournera des object Customer ? donc le service connait mes classes métiers ?

Je vais réfléchir et approfondir un peu ce soir.

A demain et encore merci .

[GuruuMeditation]

Passer une requête SQL ne me parait pas une bonne solution. Principe d'encapsulation. Le client ne devrait rien savoir de la structure DB. Et en plus, si tes champs changent pour une raison ou une autre, il faut refaire toutes les requêtes sur ton appli client.

Peut-être que je me trompe mais il parle d'une base de données distante. Alors je ne pense pas qu'il veuille tout passer en locale s'il s'oriente vers SQL Lite

Ouops, autant pour moi. J''avais pris "c'est que l'on ne peut accéder à une base de données distante qu'à partir d'un service web" comme "pour le moment on ne peut avoir de DB que sur serveur distant. Toujours vrai?".

[Invité]

h2s84 je comprends que mon service peut m'exposer plusieurs méthodes avec ou sans paramètres. Mais cela m'impose de modifier mon service (ajout de méthode) dès que mon appli cliente évolue et me demande d'autres infos. Apparemment un développement en parallèle s'impose donc.
Je suis de nature assez féniant (paraîtrait que c'est une qualité chez les développeurs ) je me vois bien faire un service avec une méthode GetData(string sql) ou sql serait ma requête et hop le service me retourne mes données ... mais j'ai l'impression que vous allez me contredire, par exemple sur le type de retour...

Tu peux faire un service WCF avec une et une seule opération sans te faire chier avec le type de retour ou du type en paramètre mais... ça demande du TAF quand même. Bon il y a un exemple que Sacha Barber présente dans une application exemple ici. Avec cette méthode tu modifieras jamais ton service WCF.

D'ailleurs pour l'exemple que tu me donne h2s84, GetCustomers(), cette méthode me retournera des object Customer ? donc le service connait mes classes métiers ?

Elle te retournera tes DTO. Par exemple CustomerDTO. Le service ne connait pas tes classes métiers. Mais tu auras besoin de méthodes de conversions de Customer vers CustomerDTO et inversement.

[max_25]

Bonjour,

Merci pour vos réponses.

Je pense avoir compris, l'architecture générale.

Le service dispose de mes classes d'accès aux bases (je peux réutiliser mes anciennes classes xxxDB) avec le SQL et il a les DTO qui lui permettent de me retourner des objets typés.
Mon appli cliente elle dispose des classes métiers (avec méthode de conversion de DTO vers l'objet métier).
Pour le service le mieux et de faire une méthode par besoin spécifique.

En tout cas merci pour tout ce qui était confu hier l'est beaucoup moins aujourd'hui.
Je place en résolut puisse que j'ai les infos qu'il me fallait.

Bonne journée.