Discussion :

[LecGaël]

Quand vous parlez d'objets métiers vous voulez dire que vous faîtes des classes pour chaque objet de votre base de données ?

Car c'est pour moi encore un grand mystère, est ce qu'il faut créer des objets en c# de ce que l'on récupère via la base de données ?

[StringBuilder]

Je trouve ça en effet plus pratique.

Par exemple, si vous chargez un client depuis votre base de données, et que vous voulez afficher trois userControls :
- UCClient : affiche le détail du client
- UCListeCommande : affiche une liste de commandes
- UCListeTelephone : affiche une liste de téléphones

Dans le premier, vous voulez les détails du client, et dans les autres, respectivement les commandes du client et la liste des numéros de téléphone du client.

Ce sera appréciable de faire :

Code csharp :

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

1
2
3
4
 
myUCClient.DataSource = client;
myUCListeCommande .DataSource = client.Commandes;
myUCListeTelephone .DataSource = client.Telephones;

Et laisser la classe Client faire le boulot de charger les commandes du client et ses numéro de téléphone.

Ensuite, chaque commande et numéro de téléphone seront eux-mêmes des objets, comme ça vous pouvez définir ce qu'il se passe quand on en ajoute un, supprime un, met à jour un… etc.

Il ne vous restera alors dans les UC qu'à gérer l'affichage et les règles liées à l'affichage (si tel champ est vide, alors untel est grisé, etc.)

[Pol63]

y en a qui utilisent des générateurs de code pour créer ce genre de classe, taper des propriétés c'est pas super cool non plus

sinon tu peux regarder du côté d'entity framework
dans visual studio tu lui dis où est ta base de données, il créé toutes les classes et les liaisons entre elle
et après en une ligne de code tu peux lui dire que tu veux la liste des clients qui ont telle valeur dans telle colonne, et que tu veux récupérer les commandes et les lignes de commandes
il génère la requete lui même et remplit les objets
et après tu as la souplesse de faire SelectedClient.Commandes ou autre ...
et après tu peux ajouter un client ou une commande, supprimer une ligne de commande ... et faire .save, et il génère les requetes pour sauvegarder les modifications

en général les débutants aiment bien ca, ca évite d'avoir à coder et à apprendre le sql

[LecGaël]

Pour l'instant le gros point bloquant pour moi, c'est de coder l'interface avec les datagridView etc.
Pour ce qui est du SQL je ne trouve pas ça bien compliqué.
Là où j'ai essayé des choses et j'ai échoué c'est d'utiliser des OledBDataAdapter avec des requêtes "jointées" je n'arrive pas à gérer le CRUD avec ça.
Du coup je me suis rabattu sur des requêtes SQL simples et dans ma BDD qui est sous Access j'ai fait mo schéma relationnel avec suppression en cascade etc...

Pour ce qui est des objets ça m'intéresse, mais je ne vois pas comment le mettre en application, à quel moment "hydrater" les objets métiers avec les données de ma base, etc...

Pour ce qui est de entityFrameWork, c'est un ORM comme LinQ ? je ne sais pas si ça fonctionne avec Access... je me rends compte que c'est vraiment de la m**** Access...

[Pol63]

Linq c'est pas un orm c'est un genre de language fonctionnel intégré à c#, linq to sql ca devait en être un mais ef est son remplaçant.
Et oui access c'est nul, sql server express est gratuit en plus...

[LecGaël]

Et oui access c'est nul, sql server express est gratuit en plus...

Hélas la décision ne me revient pas...
Je suppose que EF ne fonctionne pas avec Access ? x)

[Pol63]

Je sais pas mais en général au lieu de supposer il vaut mieux demander à google

[LecGaël]

Il existerait un provider EF pour Access mais je n'ai pas trouvé de doc :/

[StringBuilder]

Hélas la décision ne me revient pas...

En effet, la décision ne vous appartient pas, mais en tant que professionnel de l'informatique, vous devez indiquer les points qui vous semblent incompatibles avec le bon déroulement des développements et de l'utilisation ultérieure de l'application.

Access a un seul et unique avantage : il dispose de son propre moteur de GUI qui permet à des non développeurs de produire aisément les écrans nécessaires pour gérer leurs données sans avoir des compétences informatiques approfondies.
=> En gros, l'avantage d'Access est de permettre à n'importe qui de faire de la merde

Ensuite, Access n'a que des inconvénients :
- Onéreux : il faut une licence Office "complète" par poste pour pouvoir en bénéficier
- Ne tient absolument pas la charge : dès que la base commence à grossir Access devient inutilisable, et pire que ça, on risque la corruption des données
- Mono utilisateur : travailler à plusieurs dans Access en partageant le fichier sur un disque réseau est extrêmement dangereux
- Non respect des règles élémentaires de la norme SQL : par exemple, utilisation de * au lieu de % dans les like
- Support très pauvre des fonctionnalités SQL : la couverture du SQL d'Access n'englobe même pas SQL89 dans son ensemble
- Peu performant : à part travailler dans des fichiers XML à la main, vous aurez du mal à trouver plus lent qu'Access

Bref... si vous ne pouvez pas prendre la décision, demandez au moins quelles sont les motivations à utiliser Access à tout prix, et n'hésitez pas à argumenter pour ou contre les différentes solutions. Après tout, c'est votre métier.

Les alternatives à Access :
- SQL Server Express ou SQL Server LocalDB : gratuit, aisément packageable avec le programme, très performant, multi-utilisateur, limitations largement supérieures à celles d'Access, la plupart des exemples, tutos et docs C# utilisent SQL Server
- SQLite : gratuit, intégrable directement dans le programme, très performant pour de petites bases, mais mono utilisateur, limitations largement supérieures à celles d'Access, le reste des exemples, tutos et docs C# utilisent SQLite
- Vous pouvez aussi partir sur d'autres SGBD plus ou moins gratuits que sont PostgreSQL, MySQL ou Oracle XE par exemple, mais ils n'apporteront rien de mieux par rapport à SQL Server Express ou SQLite

[LecGaël]

Je suis d'accord avec vous et j'ai essayé de vendre SQL server sans réussite, je ne suis qu'un apprenti en Électronique et informatique industrielle, lorsque je parle d'informatique à mes supérieurs c'est comme si vous tentiez d'expliquer les couleurs à un aveugle...

[Noxen]

Il existe des moyens de se protéger au moins en partie de ce genre de contraintes et qui répondrait à ton besoin de clarté et ça consiste à faire des modules logiques avec chacun ses propres responsabilité. Je ne sais pas quel est l'état actuel de ton code, mais souvent du code de débutant ça ressemble à une fonction button1_click de 150 ligne qui crée une requête SQL en dur avec des string concaténée à des textbox1.Text, ouvre connexion, envoie la commande et fait tout un tas d'autres choses ; c'est comme ça, on en est tous passé par là avant d'apprendre à faire mieux. Peut-être que pendant ta formation on t'a présenté des modèle comme MVC (Model / View / Controller) ou les architectures 3 couches (Présentation / Métier / Persistance). Bien que ces modèles datent un peu ils restent souvent pertinents.

Ma proposition serait de faire plusieurs dll à côté de ton exécutable applicatif :
- une couche de contrats de services ;
- une couche de services implémentant les contrats de services ;
- une couche de contrats de persistance de données ;
- une couche de persistance concrète implémentant les contrats de persistance ; en l'occurrence tu planquerais dedans tous les appels à Access.

Concernant l'interface graphique le conseil de créer des UserControls spécifique reste valable. Ça peut paraître un peu lourd comme ça et c'est vrai qu'il est parfois un peut fastidieux de devoir modifier plusieurs composants pour une évolution mineure. Mais il y a d'abord un gain immédiat en terme de lisibilité et de répartition des responsabilités : par exemple une règle métier trouvera naturellement sa place dans la couche de services. Par ailleurs il pourra y avoir un gain en cas d'évolution de méthodologie. Par exemple si tu obtiens l'abandon d'Access au profit d'une base de données en ligne tu n'auras que la couche d'accès aux données à modifier ; s'il est décidé de remplacer l'application en client lourd par une application web il n'y aura que la partie web à créer, le reste sera parfaitement réutilisable.

[LecGaël]

J'adorerais apprendre tout ça ! mais vers quels source je peux m'orienter pour apprendre ?

[Pol63]

Idéalement il faut être dans une équipe avec des gens qui maîtrisent tout ça.
Si tu es le seul développeur ça va être compliqué de faire une archi complexe.
Après il faut aussi voir le besoin sur l'appli. Si c'est une appli interne utilisée par une seule personne développer des webservices sera une perte de temps.
Par contre faire une couche d'accès aux données (DAL) ça permettra de la modifier plus tard.
Ça en gros c'est une ou plusieurs classes que tout le monde appelle des qu'il veut lire ou écrire dans la base et seule la DAL contient des requêtes et des accès à la db.

[LecGaël]

D'accord, peut être un jour qui sait :/

[Noxen]

C'est effectivement le cas idéal que je présente, en pratique il n'est pas toujours possible de faire comme on veut. Dans le cas présent je pense quand même que tu te faciliteras la vie en faisant au moins une DAL, comme le conseille Pol63.