Discussion :

[caalors]

Bonjour,

Je viens du monde du web et je suis en train de développer une application pour client lourd (Windows) en C#.
Cette application va rechercher des données via une API Rest pour les sauvegarder en base de données (Sqlite) et les présenter à l'utilisateur (pour sa propre utilisation)

J'ai plusieurs objets, un pour la bdd, un autre pour l'API Rest, un pour les préférences, etc.

Mais comment architecturer l'ensemble sachant qu'en plus il y a des dépendances entre objets ?
Par exemple ma classe pour l'API Rest va avoir besoin de la classe des préférences pour connaître le login / mot de passe de l'utilisateur sur le service Rest ainsi que de la classe de base de données pour sauvegarder les données. Le formulaire de gestion des préférences doit lui aussi manipuler la classe de préférences, etc.

Est-ce que ma fenêtre principale (je suis en winform) doit instancier tous les objets et les passer les uns aux autres (et avoir tout un tas de variable globales), est-ce qu'il faut passer par des classes statiques appelées dans les autres classes selon le besoin, bref ne je vois pas trop comment faire.

Merci de vos idées.

[Lutarez]

Bonjour,

Il existe en POO un principe important qui est malheureusement souvent négligé : le principe de responsabilité unique. Pour le dire rapidement, une classe doit avoir un seul et unique rôle. Ce principe vise à simplifier le code, et non à être une contrainte.

Dans ton cas, ta classe permettant d'appeler un service REST et de mettre à jour une base de données enfreint ce principe de responsabilité unique, car ta classe à deux responsabilités : interroger le service REST ET mettre à jour la base de données. On pourrait même dire 3, vu qu'elle va chercher les informations de connexion. Dans des cas comme celui-ci, c'est normal que tu rencontre des problèmes de dépendances.

La solution reste cependant simple. Actuellement, ton plus gros problème est de savoir comment gérer les interactions entre tes classes. Il te suffit alors de créer une quatrième classe, qui va être responsable de gérer les trois autres, en faisant passer l'information entre tes trois classes actuelles. C'est un peu le même principe que les contrôleurs du modèle MVC, si tu connais.

Donc pour résumer, voici un peu comment pourrait fonctionner la mise à jour de l'interface graphique :

• le contrôleur récupère les préférences depuis la classe dédiée
• le contrôleur demande les informations à la classe qui communique avec le service REST, et donnant les informations de connexion précédemment récupérées
• le contrôleur ayant reçu les informations, il demande à la classe responsable de la mise à jour de la base de données de ... mettre à jour la base de données avec les informations fournies par le service REST.
• l'UI n'a plus qu'à venir récupérer les informations dans la base de données

A noter que la classe permettant de gérer les autres entre elles peut très bien être ton interface graphique. Cette solution marche bien pour de petits projets. Au final, tu n'instancies les objets que pour récupérer les informations que tu souhaites (ou pour mettre à jour la BDD).

[caalors]

Bonjour Claude,

Merci pour ta réponse.
Je vais mettre en oeuvre en ajoutant des fonctions asynchrones pour avoir une interface non bloquante.

Bonne soirée