Architecture logicielle: les dll

Signaler
Messages postés
148
Date d'inscription
lundi 12 février 2007
Statut
Membre
Dernière intervention
9 novembre 2013
-
Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
-
Bonjour à tous,

J'ai fait pas mal de petits projets (VB6, VB
.net) que je voulais réunir au sein d'un seul. J'ai réalisé aujourd'hui
qu'un bon moyen d'y parvenir serait peut-être de passer par des
bibliothèques de classe, puisqu'elles ne sont pas typées par le langage
de programmation dont elles proviennent (vrai?).

En gros,
l'idée, c'est de faire un projet mère avec juste l'aspect graphique
pris en charge et d'y mettre des handler pour tous les évènements
possibles venant de mes dll, (voire même d'une seule, qui référence
toute les autres). De cette façon là, est-ce que j'ai bien compris:
j'ai une séparation du code, un approche objet, et une fusion parfaite
et sécurisée des différentes briques logicielles.

Est-ce que
cette approche est viable? Est-ce que ça risque de produire des soucis
à long terme? Et est-ce qu'il est possible de faire en sorte que mes
dlls ne puissent être lues par un tiers? (j'ai des mots de passe en dur
dedans )

Je
sais que la question est assez vaste, et étant éternel débutant, j'ai
quelque fois une approche un peu naive, merci de m'éclairer!

1 réponse

Messages postés
3983
Date d'inscription
jeudi 14 juillet 2005
Statut
Membre
Dernière intervention
30 juin 2013
13
Mieux vaut développer le coeur de l'application dans le même EXE (je parle ici VB6 et .NET).
Les add-ons, par contre, doivent être gérés en DLL.
Et rien n'empêche l'utilisateur de lire le contenu de l'EXE ou de la DLL dans un éditeur hexadécimal !