Discussion :

[Invité]

Bonjour,

Je suis en train de développer un programme de gestion de relation client en C# en guise d'autoformation.

J'ai une classe DBConnect qui se charge de la connexion à la BDD (Access) et une classe Client qui hérite de DBConnect. Client possède les méthodes habituelles CRUD et d'autres.

Ma question peut sembler naïve, mais je débute la POO : Est-il concevable que ma classe Client ouvre la connexion à la BDD à chaque méthode ? (création d'une fiche client, lecture, comptage, etc). Cela a pour effet une répétition de code du genre :

Code C# :

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

1
2
3
4
5
6
7
8
9
10
11
if (OpenConnection() == true)
{
    query = "SELECT * FROM clients ORDER BY id DESC";    
 
    OleDbCommand cmd = new OleDbCommand(query, connection);
    OleDbDataReader dr = cmd.ExecuteReader();
 
    // ...
 
    CloseConnection();
}

Je me dis qu'il serait mieux d'ouvrir une seule fois la connexion et la fermer à la clôture de l'application... non ?
En tout cas, je ne vois pas comment procéder (si toutefois cela se pratique...).

Je suis preneur de tout tuyau.

Merci.

Fred

[J@ckHerror]

Bonjour,

Aucun problème pour ouvrir, requêter et refermer la connexion. C'est même la bonne pratique je dirais. En tout cas il ne faut pas ouvrir et laisser ouverte la connexion si rien ne se passe dessus.
Tu peux y aller comme ça.
Ce que je dis concerne les SGBD classiques, je ne considère pas Access comme un SGBD classique, mais tu dis être en formation donc adopte tout de suite les bonnes pratiques.

J@ck.

[Invité]

Merci pour ta réponse J@ck

Tu dis que Access n'est pas un SGBD classique... quel est la meilleure option alors ?
J'ai pris Access car la bdd est facile à créer. Access ne me sert en rien à la gestion, uniquement à la création des tables...

Fred

[J@ckHerror]

Pour moi un sgbd classique c'est un produit comme SQL server, Oracle, AS400 ... voir MySQL ou PostgreSQL.
En gros un sgbd que tu mets sur un serveur.
Dans ton cas renseigne toi du coté de SQL-Lite par exemple, je entends souvent parler mais je n'ai jamais testé...
Mais oui abandonne access dès que possible, déjà il est très très peu probable que tu le rencontre dans un univers pro (ou alors sauve-toi vite de là), et idéalement installe toi un sgbd sur une machine (pas besoin d'énorme ressource non plus si tu es le seul à taper dedans) genre un sql server express (gratuit) ou un MySQL...
Si tu n'as pas de deuxième machine met une instance sur ta machine de dev (ou dans une VM)...
L'idée étant de te former, tu rencontreras peut-être des problèmes que tu ne pourrais pas avoir avec un truc local, comme les droits d'accès, les temps de réponses pouvant varier ... etc etc.
De plus maintenant son petit serveur maison reste un truc plutôt intéressant mais si nous ne sommes pas des admin...

Bon code,
J@ck

[Invité]

Merci pour ta réponse très claire.
En revanche, j'ai pensé à Access car je développe un programme qui est censé fonctionner en local. Je pense simplement à la simplicité d'utilisation, notamment pour l'installation du logiciel une fois terminé... (pas besoin de serveur). Par la suite, je compte intégrer un système de backup sur une bdd distante MySQL (que je pratique pas mal en tant que développeur web).
Mais je pense que tu as parfaitement raison, et je vais me pencher sur l'utilisation de SQL server/lite, voire MySQL en local (pas pratique à mettre en place dans le cadre de l'installation de l'application, car il faut l'installer séparémment...). J'ai de quoi héberger un tel serveur sur une autre machine, voire à distance sur serveur dédié.

Je ne suis qu'au tout début de mon projet et je veux partir sur LES bonnes bases et ne pas avoir à recoder tout un pan dans 2 ou 6 mois pour rien. C'est pour cela que je ne m'attache pour le moment uniquement à la gestion des clients. Resteront les articles, les fournisseurs, les ventes, les commandes, le sav, etc... que du bonheur

Merci!
Fred

[J@ckHerror]

hum hum intéressant tout ça !

Pour une appli fonctionnant en déconnecté/local je ne suis pas expert, je ne l'ai jamais vraiment fait. Va voir vers SQL lite en effet, ou PostGreSQL et FirebirdSQL qui semble faire le job également, je n'ai rien a te conseiller désolé
Si en local tu ne veux conserver que quelques paramètres, tu peux le faire par les settings de l'application ou plus généralement dans un fichier placé à coté de l'exe.

Sinon, en effet je te recommande de bien réfléchir à l'architecture de ton appli, particulièrement si tu sais déjà que tu devras changer de sgbd en cours de route, et avoir forte évolution. As tu déjà des idées/plans/réflexion en ce sens ? ou en est tu ? tu veux faire du développement en couche ? si on te parle de repository ça te parle ? Entity framework ?

La bascule de access vers autre chose sera d'ailleurs un bon test pour toi...

J@ck.

[Invité]

En fait, l'appli fonctionnera essentiellement en local. L'idée m'est venue d'un ami qui monte sa boite et qui aura besoin d'un logiciel de gestion de ses ventes d'ici la fin de l'année au plus tôt. L'accès à une BDD distante ne servira qu'à sauvegarder la BDD locale (chaque heure, chaque soir après la clôture de caisse,... à convenir).

Concernant les settings, j'ai déjà chatouillé un peu le concept. C'est prévu de l'intégrer dans le projet.

Je ne compte pas changer de SGBD en cours de route... mais trouver la bonne avant de me mettre définitivement sur le chemin définitif du développement. Les repositories je connais... Git, c'est ça ? J'ai un compte sur GitHub et je m'en sert pour mes développements. Super pratique! Le développement en couche me parle oui (MVC), je connais bien le principe en développement web (via Symfony entre-autres). Intégrer le concept en C# est encore flou pour moi et justement je commence à me documenter sur Entity Framework... à suivre

Je ne suis pas professionnel en développement, mais j'aimerais le devenir. Je m'autoforme depuis pas mal de temps maintenant. Il y a 15 ans, je développais en pur procédural (PHP/MySQL) et c'était "simple", mais pas très sûr niveau sécurité. La POO m'intéresse, me fascine, me passionne... et je découvre (et intègre) chaque jour de nouveaux concepts. J'espère pouvoir un jour sortir de mon train-train de vendeur (d'où mon appli de gestion de relation client, car je connais les besoins en la matière) et devenir développeur

Fred

[Pol63]

le choix de la base de données se fait sur plusieurs critères, notamment l'accès réseau ou local, et la volumétrie

pour du local il y a dans l'ordre l'xml, access, sqlite, sql server localdb
xml c'est bien pour quelques trucs qui bougent pas trop
access c'est bien pour débuter, et encore
sqlite doit un peu mieux suivre les normes, ca reste une base fichier comme access
sql server localdb est un sous produit d'sql server, utile si tu as plusieurs centaines de Mo de données minimum

si un jour la personne pour qui tu veux faire le soft a un autre employé qui doit utiliser le logiciel, une base fichier ne conviendra plus, il faut alors une base réseau, hébergé sur un serveur, le dialogue entre l'appli et la base se fait alors en tcp/ip
c'est pour sql server (express est gratuit) et d'autres grands sgbdr
et à ce moment là si tu as une base fichier ca te feras quelques modifs dans le code pour migrer, surtout si tu passes d'une marque à un autre, car le langage sql ne sera pas forcément identique en tous points
migrer de sql server localdb à sql server par exemple ca passe crème, par contre commencer avec sql server localdb ca peut etre l'artillerie lourde (sqlite c'est une dll de quelques ko, localdb c'est quelques centaines de Mo via un installeur)


quand il y a une base réseau, ce qui est à la mode c'est de faire un exe sur le serveur qui fait passerelle entre les clients et la base de données (par wcf ou autre)
ca apporte pas mal de choses, mais ca reste plus compliqué à mettre en place qu'une connexion directe de chaque client vers la base


concernant la redondance de code, en général on se créé une classe d'encapsulation d'accès aux données
ce qui fait qu'une exécution de requete peut se faire en une ligne de code, et la classe qui encapsule tout contient l'ouverture de la connexion, l'exécution/retour et la fermeture de la connexion

une des bonnes pratiques en programmation c'est de factoriser
2 codes identiques ou qui se ressemblent fortement doivent être factorisés en un seul code, qui peut prendre des paramètres
ici seule la requete et ses éventuels paramètres changent d'une exécution à l'autre, ce sera donc les paramètres de cette factorisation

[Invité]

Merci Pol63 pour ta réponse !

Je pense donc me pencher de ce pas sur SQL Server Express... en fait, ça fait un moment que cela me chatouille mais c'était tellement simple de passer via Access :/
Mais il est vrai que j'ai comme projet d'ajouter un mode multi-utilisateurs (ou multi-postes) et cela ne peut pas passer par une base comme Access (ou très difficilement).

Au moment d'écrire ces lignes, je me pose une question : est-il envisageable d'utiliser MySQL ? En local, c'est assez facile à installer finalement et je possède déjà un serveur dédié distant chez OVH. Et je pense ne pas me tromper en affirmant qu'il est très facile de passer d'une base locale, à une base réseau interne ou à une base distante (sur mon dédié). Seuls l'adresse IP, le nom d'utilisateur et le mot de passe changent.

Je suppose que SQL Server est plus performant que MySQL (?). Mais dans mon cas, il n'y aura jamais des centaines de milliers de clients, ni d'articles, ni de ventes, etc. Le logiciel vise une utilisation "artisanale" et non les grandes entreprises de distribution.

Donc MySQL est-il un choix judicieux dans mon cas à votre avis ?

Fred

[J@ckHerror]

Bonjour,

Pour le cas de MySQL, je dirais Ok pas de contre indication, mais Pol63 aura un avis plus éclairé que le mien.

Par contre, vu ce que tu racontes, je me concentrerais sur une architecture qui isole parfaitement la couche d'accès aux données des autres couches. Ton projet va sans aucun doute devoir évoluer dans le temps, tu vois au début du thread tu voulais juste du local, et la maintenant on passe en multi-user . C'est normal tout projet évolue, et tout projet s'arrête lorsque son évolution n'est plus possible.
Donc pour éviter la mort dans l'oeuf de ton projet, perso je me concentrerais sur une archi qui sera peut être un poil déroutante si tu es newby (ce que tu ne semble pas être complétement ) mais très permissive et évolutive.
Plus haut, je te parlais de repository dans le sens pattern de développement.

Par exemple dans ton code tu explique avoir une classe Client qui hérite de DBConnect. Donc je comprends que chaque classe de ta couche métier sera fortement liée à ta couche d'accès aux données, cad que chaque classe métier contient le sql (CRUD) nécessaire. Ok pas mal, mais peut mieux faire. pourquoi ?
Comme la très bien expliqué Pol63 si tu change de fournisseur/marque de sgbd le sql va changer ! Si tu continue ainsi, alors un passage de MySQL vers MSSQL par exemple t'obliger à reprendre l'intégralité de tes classes métiers pour modifier le sql, et du coup tu perds la compatibilité avec l'ancien, à moins de dupliquer complétement le code avec 2 codes à maintenir, bref une forte odeur d'emmerdes en perspectives...

Si je te parle de repository c'est parce que l'idée derrière ce pattern c'est justement de changer de fournisseur de données très simplement, avec un peu d'injection de dépendance, il te faudrait une ligne de code (voir un paramétrage) pour changer de fournisseur. Typiquement tu pourrais avoir par exemple 3 repository pour te fournir tes clients, un qui contient du TSQL, un le MySQL, et un qui bosse en local à travers des fichiers plats par exemple. Par contre derrière, ta couche métier est elle inchangée ... donc la logique métier et garantie, peut importe la source de donnée.

J@ck.

[EDIT] J'ai retrouvé un petit exemple que j'avais déjà proposé ICI

[Pol63]

de ce que j'ai lu sur mysql par des pros, c'est un genre d'access
ca ne suit pas les standards, ca ne gère pas autant de choses, et il y aurait des absurdités dans le moteur
de là à dire que ca ne convient pas pour gérer 2 pcs alors que des sites avec des millions de connexions l'utilisent je n'irais pas jusque là
(= ca peut tout à fait convenir)

après avoir une base de données sur le web qui est ouverte ca ne se fait pas trop je crois, on préfère alors utiliser des webservices pour éviter quelques failles de sécurité potentielles
si tant est qu'ovh ou autre permettent de laisser la base de données ouverte sur le web, généralement les bases ne sont ouvertes qu'en local, pour l'accès au côté serveur d'un site web ou de web services
par contre une base de données ouverte sur un serveur local ca se fait bien, par contre il faut acheter un serveur ^^

un webservice pour info c'est une appli qui expose des méthodes et fonctions, en .net on utilise généralement WCF pour faire des webservices
c'est plus limité qu'un accès direct à une base de données ou le langage sql est interprété, ici c'est à toi d'écrire ce qui est faisable
genre public void InsertClient(string nom, string adresse ...)
ce void est ensuite accessible côté client
ou encore public List<Client> GetClients
le webservice s'occupe de gérer les autorisations d'accès aux méthodes

perso je suis pas super fan même si c'est la norme aujourd'hui, ca demande quand même beaucoup de code


côté accès à la base de données il y a aussi des ORM comme Entity Framework
ca permet d'éviter d'écrire du code sql
et dans certains cas ca doit faciliter le changement de sgbdr
une fois relié à ta base ca génère du code (une classe par table) du coup ca peut gagner pas mal de temps sur des petits projets
au lieu d'écrire une requete, puis de lire le résultat on écrit directement du linq avec un truc du genre

Code :

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

var listeClientsAvecCommandes = entities.where(c=>c.nom.contains(filtreNom)).include(c=>c.commandes)

cette ligne s'occupe d'ouvrir la connexion,
de générer la requete (select ... from clients inner join commandes on clients.idclient = commandes.idclient where clients.nom like @filtrenom)
et de remplir les instances (clients et commandes ici, commandes étant une propriétés de type collection sur client vu qu'EF aura détecté la clé étrangère)
EF + WCF c'est possible, mais ca n'est pas aussi souple qu'EF directement sur la base de données
comme tout le reste ca n'a pas que des avantages, mais ca en a certains

[Invité]

Merci J@ck et Pol63 pour ces réponses très complètes !

Pour résumer vos deux réponses complémentaires, je dois donc utiliser Entity Framework pour faire quelque chose qui tient la route. Le concept je le connais car j'ai utilisé Symfony et son ORM Doctrine en tant que développeur web, et j'ai trouvé ça passionnant. Il me reste donc à transposer ça sur C#.

Concernant l'accès à MySQL sur mon serveur OVH, cela fonctionne. J'ai réalisé un test il y a quelques semaines et tout est paramétré et opérationnel. En revanche, il est vrai que ce n'est certainement pas le moyen le plus sûr. Mais oublions le côté "backup distant", ce n'est pas ma priorité. On peut très bien envisager un backup local et "sécuriser" les données en les envoyant via FTP sur un serveur distant (sous forme d'un ZIP par ex.), pour ensuite les récupérer, plus ou moins manuellement et restaurer la base à une date antérieure...

Donc : Entity Framework ! J'ai du pain sur la planche ! Mais je m'éclate

Fred

[Pol63]

je dois donc utiliser Entity Framework pour faire quelque chose qui tient la route.

"sécuriser" les données en les envoyant via FTP

je serais tenté de dire qu'il y a ici 2 oxymores

j'ai dit qu'EF était pratique sur des petits projets, pas que c'était nécessaire pour faire quelque chose qui tient la route
certains pros disent que c'est une abération (sur des gros projets surement)

le ftp de mémoire n'est pas quelque chose de sécurisé
mais dans le principe oui, envoyer un backup quelque part ca va bien

[Invité]

j'ai dit qu'EF était pratique sur des petits projets, pas que c'était nécessaire pour faire quelque chose qui tient la route
certains pros disent que c'est une abération (sur des gros projets surement)

Mon projet reste un petit projet... enfin il me semble...

le ftp de mémoire n'est pas quelque chose de sécurisé
mais dans le principe oui, envoyer un backup quelque part ca va bien

Le transport, en effet, n'est pas sécurisé à la base, mais on peut passer par des connexions ssh qui le sont... Et rien n'empêche de crypter les données envoyées...

Mais bon cette histoire de backup sur un serveur distant ne se réalisera peut-être pas au final. J'ai pensé à cette fonctionnalité sans vraiment y réfléchir profondément. Je verrai à l'usage et ce sera probablement une des dernières que je developperai si besoin est. Des sauvegardes locales suffiront probablement.

Fred