DLL et gestion de données

Bonjour à tous,

je suis confronter à un problème de taille :p

j'aimerai stocker dans une dll une petite base de données clients contenant des informations comme:

-ID client
-Nom Client
-Prenom Client...

Cette dll sera utilisé par la suite par un autre programme qui viendra récupérer les informations...

Aujourd'hui je ne sais pas comment structurer tout ça:

-faire une liste ? mais le problème c'est que j'ai peur de saturer la ram lors du chargement de la dll.
-créer un objet pour chaque client ? cela va faire énormement d'objet sachant que la base est constitué de quelque milliers de clients.

Pouvez vous me donner votre point de vue sur ce problème ?

merci

Citation:

---

Envoyé par movlw

j'aimerai stocker dans une dll une petite base de données clients contenant des informations comme:

-ID client
-Nom Client
-Prenom Client...

---

Il y a peut-être une confusion sur l'utilité et l'utilisation d'une dll... Une dll est un bout de code qui peut-être partagé entre plusieurs applications. On ne stocke pas de données à l'intérieur ! sauf peut-être des icônes... à la rigueur. Tu ne peux pas enregistrer d'éléments dans une dll. Enfin je ne sais pas si c'est ton intention mais c'est ce que raconte ton message. Peut-être que je comprends mal ta pensée.

Citation:

---

Envoyé par movlw

Cette dll sera utilisé par la suite par un autre programme qui viendra récupérer les informations...

---

Oui on partage une dll avec un ou plusieurs assembly

Citation:

---

Envoyé par movlw

-faire une liste ? mais le problème c'est que j'ai peur de saturer la ram lors du chargement de la dll.
-créer un objet pour chaque client ? cela va faire énormement d'objet sachant que la base est constitué de quelque milliers de clients.

---

Dans ta dll tu peux créer une classe qui permet d’interroger ta base de données.
Tu peux également créer une classe qui représente un client (nom, prénom, société, adresse, etc...). En fait toutes les colonnes de la table client dans ta base de données.
Une méthode qui te permet de récupérer tes clients dans une autre classe qui utilise ta classe de pilotage de la base et qui te retourne une liste de clients.

Question RAM cela dépend vraiment de ce que tu as dans ta base de données.
Si ça se limite à 15 colonnes type string ou int ne t'inquiète pas on a de bon PC maintenant ;) et puis 15 * (int)8 octets * 5000 clients = 585 Ko. Ça devrait passer. Sauf si pour chaque client tu stockes une vidéo de présentation du client; là je dis attention.
Bref peut-être que tu peux récupérer de façon "intelligente" certains clients au moment où tu souhaites afficher ? Libérer la RAM une fois l'affichage ou la modification effectuée ? Dans le sens où il est inutile de te brimbaler 5000 clients tout au long de l'exécution de ton logiciel.
Tout dépend après de la représentation graphique que tu veux donner à des clients. Question de la pertinence de l'affichage de 5000 clients ? Tout ça tout ça...

Je ne sais pas si j'ai répondu à ta question ? C'était assez ouvert donc voilà au moins mon point de vue ;)

malheureusement je ne peux pas interroger la base de données.

Lorsque je fais appelle à la dll, elle est chargée en mémoire ?

C'est à dire tu ne peux pas interroger la base de données ?
Pas de BDD = pas de données ;)

Lorsque tu fais appel à la Dll, la Dll est chargée en mémoire. La base de données non.
La dll te donne accès à un ensemble classes, attributs et de fonctions. Non pas aux données de ta base de données.

disons que j'aimerai embarquer une application et la dll dans une clé usb pour lire les données directement dessus, je vais également mettre en place une clé pour protéger les infos.

D'ou la question

Citation:

---

Envoyé par movlw

disons que j'aimerai embarquer une application et la dll dans une clé usb pour lire les données directement dessus, je vais également mettre en place une clé pour protéger les infos.

D'ou la question

---

Tu peux peut-être ajouter une ressource à ton projet, genre un fichier XML qui ferait office de base de données?

Bonne idée ! du coup le fichier xml est lui aussi compilé avec la dll donc protégé ?

bonsoir,

nul besoin de tergivercer..... cherche du côté de la serialisation xml.
Il y a des exemples dans des discussions recentes sur les forums vbnet et c#

@+

Je m'excuse mais je n'ai jamais entendu parler d'un fichier ressource dans lequel on peut lire et écrire et qui est compilé dans une dll...

Tu as aussi l'option d'embarquer une base de données fichier avec SQL Compact Edition.

Tu auras un fichier .sdf et tu peux complètement tout faire tourner sur une clé USB. C'est facile, simple, rapide... Et si tu veux vraiment du SQL, beh tu seras servi...

Un coup de nuget, et basta !!!

il n'y a donc aucun moyen stocker intelligemment une "base de donnée" dans une dll ?

Ce n'est pas fait pour ça. Ça sert à stocker du code : https://msdn.microsoft.com/fr-fr/lib...(v=vs.90).aspx

De plus les données d'application sont les bienvenues dans le répertoire AppData depuis > XP :

Code:

---

1 2 3 4 5

var repAppDataApplication = new DirectoryInfo( Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) , Application.CompanyName , Application.ProductName));

---

Là tu peux placer ton fichier de base de données (SqlCe, SQLite, MongoDBn, Firebird, etc...) l'utilisateur ne viendra pas y farfouiller par hasard ;)

Il donc impossible d'accompagner un logiciel d'une "base de données" qu'on pourrait stocker dans un fichier dont l'accès est sécurisé et controlé ?

le problème vient que tu pars du principe qu'une dll c'est sécurisé
mais ca ne l'est pas du tout, on peut voir ce qu'il y a dedans, et même s'il est possible techniquement d'avoir une base de données dans une dll, on peut décompiler la dll facilement ...

A bon ? Je pensais qu'une dll était impossible à décompiler

en .net ca se fait en un clic
sur d'autres langages ou sur .net native c'est un peu plus compliqué mais c'est faisable

En un clic il est peut être possible de récupérer le nom des classes les attributs les fonctions mais pas le contenu des fonction

Bonsoir,

Je rejoins Pol63 que je salue au passage, des outils comme :

- Dnspy (editeur d'assembly, decompileur et debugger)
- Reflector (decompileur et debugger)
- DotPeek (decompileur)

...etc ...et j'en oublie certainement ....

permettent aisément d'accéder en clair au code source d'une application ou d'une librairie de classes.

Les obfucateurs comme :

- Confuser
- ConfuserEx
- Smart assembly
- DotFuscator
- AppFuscator

...et j'en oublie bien d'autres ...

sont deobfuscable grâce au renommé outil :

- De4Dot
- et bien d'autres outils home made by CodeCracker

Voilà en somme à quoi se résume la sécurité en DotNet !
Si tu veux une application sécurisé il faut soit :

- changer de langage de programmation (exclure le DotNet ou un langage interprété)
- conserver le langage DotNet mais opté pour un échange de données sécurisé type client/serveur, protocole de cryptage avec hébergement du noyau de ton code source côté serveur
- coder un obfuscateur maison (j'en avais codé un perso que j'ai rendu publique : DotNetPatcher c'est pour cela que je parle de tout ça en connaissance de cause) combiné au protocole de sécurisation Server side (ligne précédente)

A+

Tout est beaucoup plus clair merci !