Version imprimable
Bonjour,
J'ai honte mais je me permets de faire un double post.
En effet, j'ai posté ceci dans le forum C++Builder et ça n'a pas l'air d'intéresser grand monde.
http://www.developpez.net/forums/viewtopic.php?t=410907
La question étant de savoir si dans le cas d'une application avec plusieurs modules, il vaut mieux un EXE par module ou pas.
d'avance merci.
Simon
Salut
C'est bien difficile de répondre à ta question dans l'absolu. Tu peux considérer plusieurs axes de réflexion.
Le déploiement
Veux-tu déployer tous les modules ou seulement quelques uns en fonction du client ?
Morceler un programme en plusieurs modules séparés (dll ou exe) peut poser des problèmes de cohérences en termes de versions des différentes modules. Un exécutable unique simplifie la gestion de version car tu n'a pas à te soucier de la compatibilité entre les différents modules d'un exécutable morcelé.
La séparation des modules peut dans certains cas amener à des économies de mémoire.
La cohérence fonctionnelle
Est-ce les modules sont relativement indépendants ? Y a t'il un intérêt réel à séparer les modules en termes de programmes ? Peut-on récupérer un module pour le greffer dans un autre programme ?
Le fait de produire des modules en exécutables séparés entraîne souvent une surcharge en termes de communication (si les modules doivent communiquer ensemble), c'est beaucoup plus simples à résoudre dans un exécutable monolithique.
Ce ne sont que des pistes de réflexion. Il faut que tu réfléchisses à la finalité de ton application et que tu arrives à préciser l'intérêt d'une telle séparation.
cdlt
e-ric
Voila, c'est exactement le genre de confirmation et réflexion que je voulais.
En fait, les modules sont vraiment des "morceaux" d'une appli unique. Ainsi ce sont différentes interfaces pour une même base de données.
L'accès aux différents modules sera gérér d'un point de vu de droits d'accès donc l'ensemble des modules sont livrés ensemble, la restriction se fera à l'ouverture de session.
J'avais en effet identifié le problème de versioning avec des EXE séparés.
L'idée de les séparer était uniquement lié à la taille de l'EXE, sachant que de toute façon, on gère la majorité des fenêtres en dynamique pour alléger la charge en mèmoire notamment.
Mais il est clair que c'est au départ, une seule et même appli avec des modules indépendants en termes de fonctionnalités (encore que certaines sont communes) mais dépendants en termes de données.
Pour être plus précis, le projet consiste justement à proposer une appli unique en lieu et place d'un multitude de bases Access.
Je pense que j'ai ma réponse mais les bonnes idées ou expériences restent les bienvenues.
Merci
Simon
Salut,
tu peux le faire :) mais maintenant il te faut faire un choix pour respecter les régles.Citation:
Envoyé par say
Souhaites-tu placer en résolu celui du forum C++ Builder ?
Moi aussi je me suis poser plusieur la fois la question et j'ai trouvé une réponse qui me convient !
Jai eu exactement le probleme que toi , plusieur logiciel qui se connecté a la meme base de données. Et différentes personnes pouvant avoir certain logiciel que d autre ne posséder pas.
La solution que j'ai utilisé est de tout mettre dans un seul Exe (avec ces Dll). C'est plus simple pour moi au niveau de la distribution du logiciel, je n'ai pas de cas particulier à gerer , je donne donne le meme CD a tout le monde.
Aprés les utilisateurs utilisent un login et un password pour se connecter au logiciel ce qui me permet d'activer ou pas les différents modules.
Et pour finir , pour éviter de me déplacer poste à poste afin de mettre a jour le logiciel (ok ok je suis un peu faignasse :oops: ), je lui ais intégrer un système de mise a jour automatique par le réseau.
Faut dire que ça simplifie aussi la programmation, si il y a une évolution a faire sur 20 modules, c est plus simple vu que ce st le meme projet. Plus besoin d'éditer 20 projets et de perdre du temps.
:oops: a y est, c'est fait :oops:Citation:
Envoyé par Laurent Dardenne
rvzip64, je suis à priori parti pour la même solution, un exe, plusieurs modules dont les accès sont gérés par privilège.
Nous avons nous aussi prévu une mise à jour auto en ligne :)
En revanche, la taille de l'exe est pas énorme?
c'est un peu ça qui nous inquièter
merci
Simon
Pour le logiciel qui permait d'accéder à la base de données l'exe et les librairies font 8.80Mo.
Mais vu que pour le transfert par réseau je compresse le programme dans un rar ça tiens sur 2.37 Mo.
Pour le système de mise a jour par réseau 800ko.
Aprés le système est loin d'etre parfaitement optimisé.Je suis sur que je peux grapiller quelques centaines de kilo octets, par ci par la.
re,
2 questions :
ton exe, c'est sa taille après compil donc de base. Je dis ça parce que pour Builder il existe un logiciel permettant de le compresser, par exemple pour l'instant je passe de 3.8 Mo à 800 ko.
En ce qui concerne l'utilisation mémoire, est-ce que la taille de l'exe a une influence dessus? et combien ton programme prend en mémoire?
merci
Merci :ccool:Citation:
Envoyé par say
Delphi n'utilise pas de système de compression , aprés tout dépend si tu inclu les paquet dans l'exe ou pas ....
En ce qui concerne la taille de la mémoire, beh ça va dépendre un peu de ce que tu fais dans ton programme, c'est assez variable...
Un tableau d'integer de 2000*2000 prendra toujours plus de place qu'un simple integer.