Discussion :

[portu]

Bonjour a tous, voila, j'ai un gros programme de comptabilité a faire.
Cette application contiendra beaucoup de fenetre. Chaque fenetre sevira a faire une action : bilan, la saisie, gerer les comptes,etc etc...
Le programme repose sur quelques db.
Ma premiere idée etait de créer une application qui servira d'interface, et de créer des dll pour les autres fenetres qui serviront a faire des action dans les bases de données. Cette idée me parait plutot bien point de vue legereté de l'appli , et de maintenantce, ici que d'ajouter des plugins en dll.
Enfin , je m'y connais pas trop sur les gros projets donc, avis aux connaisseurs.
Je peux aussi tout tapper dans un exe mais bon, je trouve pas ca vraiment tres legé , et pour la maintenant , ca peut etre lourd.

Qu'en pensez vous ?

[PsychicStorm]

je dis peut être une connerie mais je crois que tu prends le problème dans le mauvais sens.
DLL = dynamic Link Library
L'interêt des dll est qu'ils puissent être utilisé par plusieurs executables ou encore de regrouper des fonctions qui pourront être utilisés par les versions futures d'une application.
ex : ça t'évite te recoder les fonctions si tu développes la version 1 sous visual studio et la version 2 sous delphi.
l'usage des dll ne va pas forcément rendre ton appli plus légère ou encore faciliter la maintenance.

Ce qui va rendre ton appli légère, c'est plutot le compilateur qui va faire le boulot d'optimisation que toi ou encore ta façon de gérer la mémoire(tout dépend des languages). Maintenant les optimisations nécessaires se font au niveau de l'algorithme que des optimisations exotiques de codes limite incompréhensibles.
En ce qui concerne la maintenance de ton programme, c'est et ça reste un problème de conception. Ca dépend du langage que tu vas utiliser, des contraintes, etc...

Sauf erreur de ma part, je ne vois pas pourquoi tu t'emmerdes à faire des dll pour communiquer entre ton appli et la base de données alors qu'il y a sûrement les drivers de ta base de données pour le language que tu vas utiliser. (A moins que tu n'utilises une bases de données exotiques et un language exotique) Il y a 99,999% de ta base de donnée soit fournie avec au moins des drivers ODBC(si elle tourne sous WINDWOS). Et il y a 99.999% de chances pour que ton language accepte des drivers ODBC. Sinon il y a 99.999% de chance que tu aies fait un mauvais choix de language et/ou base de données.

[portu]

Merci beaucoup pour ton point de vue.
Je vais developper cette application avec Delphi. La base de données sera controlée par le Microsoft Jet 4.0.
Donc en gros, pour toi , c'est vraiment pour ce compliquer la tache ?
Bon, moi , je voyais la chose autrement, surtout, sur le point de vue de gerer les dll. Chaque dll serait une sorte d' application tierce.
Mais bon, je pense aussi que sans l'utilisation des dll sera plus rapide niveau developpement.

Si quelqu'un a une remarque a faire sur ce sujet, qu'il n'hésite pas.

Merci a+

[PsychicStorm]

En ce qui concerne la légèreté, il vaut mieux utiliser DBexpress que ADO. hum le moteur JET est utilisé par ACCESS et par M$DE. Si tu comptes tout faire par requête SQL, je te déconseille d'utiliser ACCESS. J'ai fait l'expérience avec une appli Delphi <--> ACCESS 2000 j'ai vite regretté. Il y a des choses, des petits détails à la C.. que tu peux seulement en local via ACCESS et non par requête SQL.
Je te conseille de développer avec les mêmes versions du moteur (et pe du MDAC) y compris les services packs que sur les PCs ou le serveur où ton appli ça sera déployer. Ca t'évitera de jolies surprises au moment de la mise en production.

[portu]

Merci pour cette remarque. Je vais utiliser en effet Access par requettes SQL. Une connaissance m'a prevennu aussi de l'instabilité de la la base de donnée dans des réseaux hétérogènes (win 98 et 2000). Mon logiciel sera déployé sur des petits reseaux (10, 15 pc) hétérogènes ou pas. La base de données sera donc en partage.
Sur quelle version de windows sera t'elle la plus stable ?version serveur ?
Est ce que la version d'Access a une importance, pcq , si je ne me trompe pas,un db Access 2002 ou 2003 est formatée autrement qu'une 2000.
Le moteur Jet les prend toutes en charges ?

Faut savoir aussi que les client vont tourner sur des versions Windows et Office inconnues , allant de win 98 a xp et de office 2000 a 2003.

J'aimerais connetre ton point de vue sur ce sujet.

PS: Je m'excuse auprès des membres de ce forum si ce post dévie du sujet initial.

[PsychicStorm]

ben expérience perso en local : sur mon PC access 2000 toutes mes requêtes SQL passent, lors de la mise en production avec access XP, toutes mes requêtes avec une clause where ne passaient pas. Pourquoi ? je n'ai toujours jamais compris... faut dire que je n'ai pas non plus trop chercher à comprendre.

Là c'est à la limite de mes connaisssances sous ACCESS, je peux dire des conneries. Je laisserai tomber ACCESS parce que tu vas avoir des bugs qui vont sûrement apparaître à cause des versions différentes ou encore des bugs inéhrente à une ACCESS ou au moteur JET qui n'est pas à jour ou même une version différente. Deplus tout dépend du volume de données que ut vas traiter mais si ACCESS peut saturer ke réseau puisqu'il rappatire d'abord toutes les tables utilisées en local. Passe à une base de données client/serveur comme SQL serveur, si tu veux rester chez M$ sinon tu as MySQL, interbase/firebird.
Ma préférence irait avec Interbase/firebird car il n'y a pas mal de composants delphi pour ces base de données. de plus Interbase s'autogère très bien, d'après ce que j'ai lu ici.

serveur base de donnée 2000 ou XP pro suffisent amplement. Je pense ça ça ne gênera personne si le serveur est éteint le WE .

[ndietrich]

Salut,

Je suis entièrement d'accord pour ce qui est faire attention aux volumes de données que tu utilises avec Access, mieux vaut te baser sur une autre base si les volumes sont importants.

Je suis bien sur également d'accord pour l'utilisation de pilotes ODBC plutot que d'attaquer directement la base.

Par contre je trouve que le principe de DLL plugin est un bon principe, cela permet de modulariser ton application.
Je ne connais pas ton contexte mais en fonction des problématiques auquelles tu es confronté (mises à jour de ton soft, existance de certaines pages d'IHM sur certaines distributions de ton soft mais pas sur d'autres, etc...) c'est un principe à mettre en place au dév qui peut simplifier énormément le déploiement / mise à jour de ton soft (je suis bien placé pour le savoir)...

Bien sur l'utilisation de DLL en soit ne va pas optimiser ton application, cela peut même l'alourdir, cela n'est pas à faire si ton application est mono-client ou contient peut d'écrans, mais sur certains gros projets c'est un principe de dév qui simplifie beaucoup les autres étapes du cycle de dév...

[portu]

Encore un grand merci pour vos reponses. Pour ce qui est de l'utilisation des dll , je pense que je vais pas prendre cette idée, je pense que ca va me ralentir vu qu'en plus j'ai un delais assez court.
Pour ce qui est de la base de donnée, elle sera pas enorme d'après ce qu'on m'a dit, donc, Access devrait tj convenir. Bon , pour ce qui est de la version d'Access, suffis juste de créer la base de donnée vide de la version 2000, et de la distribuer avec le programme, comme ca, elle sera tout le temps compatible.

Enfin, je vais commencer le projet et on verra plutard les futures problemes donc, a la prochaine et merci encore.

a+