Discussion :

[giova_fr]

Bonsoir
Cela va faire maintenant 3 ans que je developpe en C#, façon autodidacte...

Et depuis fort longtemps je me demande comment organiser ma boite à outil?

Dans mes projets il y a des fonctions récurentes, au début j'avais commencé une dll GiovaFrameWork, mais j'ai rapidement abandonné le bébé car :

1. Je devais rendre mes méthodes le plus versatile que possible pour etre utile dans tous les cas de figure (trop long à developper)
2. Si je respectais pas le point précédent, j'encourrais le tres haut risque en cas de probleme avec ma DLL de devoir modifier tous mes projets en conséquence.
3. A tout mettre dans un dll, j'impose à mes programmes de charger des choses inutiles.

Apres je me suis dis, pourquoi pas faire une DLL par theme, une pour tout ce qui est Form, l'autre reseau, etc... Mais dans la pratique mes programmes ont tout le temps besoin de plusieurs de ces themes, donc ca revient au meme que de tout mettre dans une DLL.

De plus souvant je n'ai besoin que d'une de mes fonctions pour le reseau, une de mes fonctions GUI. Alors lui faire charger tout un lot de pattern juste pour une methode....

Bref, je ne sais pas comment m'organiser, à chaque fois je fais du copier/coller, ce qui est extremement mauvais.

Quelques conseils?

Merci

[Pol63]

n'avoir à utiliser qu'une fonction d'une dll n'est pas grave
.net compile le code à chaque exécution, mais au fur et à mesure. chaque membre est compilé lors du premier appel par ton code
les liaisons sait aussi faites au dernier moment
donc avoir une grosses dll boite à outils n'est pas un soucis

après il faut prévoir les cas génériques d'utilisation pour faire une méthode qui conviendra dans la majorité des cas, et faire des surcharges pour des cas qui diffèrent
rien n'empeche après de faire une méthode spécifique dans le programme spécifique qui permet d'utiliser la méthode générique avec du coup quelques lignes de plus

il faut aussi typer au plus générique, des interfaces, des classes de bases etc...

tu peux aussi faire 2 ou 3 dll, enfin c'est pas toujours simple de découper des dlls si tous les éléments s'utilisent entre eux ...


si tu nous donnes un cas concret on pourra éventuellement te donner un avis sur la manière de l'intégrer pour un spectre large d'utilisation

[kheironn]

Edit : Pol63 a posté entre-temps... je rejoins ses explications.

Personnellement, j'aurai choisi la sollution une dll (avec effectivement l'obligation de faire du générique)

1. A tout mettre dans un dll, j'impose à mes programmes de charger des choses inutiles.

Utilises-tu toutes les méthodes de chaque dll .Net chargée ? C'est pareil, tu charges des choses qui te sont inutiles...

[giova_fr]

Tout d'abord, merci pour vos réponses.

Utilises-tu toutes les méthodes de chaque dll .Net chargée ? C'est pareil, tu charges des choses qui te sont inutiles...

j'y ai égallement pensé, puis je me suis rassuré en penssant aux anciennes versions de windows surchargés de couches inutiles, je me suis alors dit que c'etait dans la politique de microsoft

Donc pour vous résumer, du fait que le lien vers la dll est static, le compilateur ne charge que ce qui est appellé dans le code, c'est bien ca?

si tu nous donnes un cas concret on pourra éventuellement te donner un avis sur la manière de l'intégrer pour un spectre large d'utilisation

Je n'ai pas d'exemple concret, c'etait plus une reflexion. Disons que j'ai des méthodes pour traiter des fichiers, les signer, calculer leur checksum, j'ai egalement des patterns pour communiquer avec une base de donnée. Des controles Winform que j'utilise souvant, etc...

[Pol63]

le jit ne compile que ce qui est utilisé oui

sinon un truc qui peut etre utile, c'est le design pattern factory, qui s'utilise soit avec de l'héritage soit avec des intefaces

par exemple

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
namespace Checksum
{
 
    public interface IChecksum
    {
        byte GetChecksum(byte[] bytes);
    }
 
    public enum TypeChecksum
    {
        code128 = 0,
        autre = 1
        // etc  
    }
 
 
    public class ChecksumFactory
    {
 
        public static IChecksum Create(TypeChecksum cht)
        {
            switch (cht) {
                case TypeChecksum.code128:
                    return new checksum128();
                case TypeChecksum.autre:
                    return new checksumAutre();
                default:
                    throw new ApplicationException("cas non prévu : " + cht.ToString());
            }
        }
 
        private class checksum128 : IChecksum
        {
 
            public byte GetChecksum(byte[] bytes)
            {
                // traitement spécifique
            }
 
        }
 
        private class checksumAutre : IChecksum
        {
 
            public byte GetChecksum(byte[] bytes)
            {
                // traitement spécifique
            }
        }
 
    }
 
}

ca permet de ne pas se soucier de ce que utilises mais comment ca s'utilise
peu importe le type de checkum utilisé ce qui t'interresse ce n'est pas comment on le calcul mais quoi appeler pour le calculer
donc depuis ton code tu déclares une variable as IChecksum, tu passes par le factory ChecksumFactory.Create(letype que tu as besoin)
et après tu ne manipules que l'interface
si une autre partie de la dll a besoin d'un objet checksum, tu la rend générique en faisant qu'elle demande un IChecksum et non pas un truc fortement typé, le code spécifique étant dans les classes implémentantes, qui elles aussi peuvent manipuler des interfaces pour des objets extérieurs

si toutes tes briques de la dll manipulent des interfaces ou des classes mustinherit elles peuvent alors tout manipuler de manière générique

tu peux mettre des interfaces de manière plus flous encore, qui seraient héritées par des types de classes totalement différentes (des controles, des checksum et autre) avec une propriété qui t'interresse de retrouver dans tous les cas

après tu peux faire des collections d'object, y mettre n'importe quoi dedans et faire des traitements liés à l'interface

Code :

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

1
2
3
4
5
6
foreach (object item_loopVariable in mylist) {
    item = item_loopVariable;
    if (item is IMachin) {
        ((IMachin)item).Traitement_spécifique_sur_les_IMachin();
    }
}

[DonQuiche]

Donc pour vous résumer, du fait que le lien vers la dll est static, le compilateur ne charge que ce qui est appellé dans le code, c'est bien ca?

Non, toute la biblio est bien chargée en mémoire. La question est donc de savoir combien elle pèse, dans l'absolu et par rapport à l'appli.

Un PC médiocre aujourd'hui a 2Go de RAM. La mémoire n'est donc pas un problème. Le temps de chargement disque, en revanche, oui. Tes applis démarrent-elles trop lentement ?

Enfin, tu peux toujours utiliser nmerge pour fusionner ta dll dans ton exe en ne prenant que ce qui est nécessaire.

[tomlev]

A tout mettre dans un dll, j'impose à mes programmes de charger des choses inutiles.

A moins que ta DLL ne soit vraiment énorme, le fait de la charger entièrement alors que tu ne vas en utiliser qu'une petite partie n'a absolument aucune importance.

Par exemple, dans la lib Dvp.NET, l'assembly principal contient des centaines de classes et méthodes, mais une fois compilé ça ne pèse que 200 Ko environ, ce qui est tout à fait négligeable sur un PC moderne.

Apres je me suis dis, pourquoi pas faire une DLL par theme, une pour tout ce qui est Form, l'autre reseau, etc...

C'est ce qu'on a fait dans Dvp.NET :

• Un assembly "principal" qui contient des trucs utilisables dans n'importe quelle appli, indépendamment de la techno UI utilisée ou de la plateforme (bon, y a quand même qq trucs qui passeront pas sous Windows Mobile ou Silverlight, mais dans l'idée c'est quasiment portable et ça devrait pouvoir tourner sur Mono par exemple...)
• Un assembly pour Windows Forms
• Un assembly pour WPF
• Un assembly avec des fonctionnalités systèmes spécifiques à l'OS (en l'occurrence Windows)
• Un assembly pour GDI (System.Drawing)

Et si besoin on pourrait en ajouter un pour ASP.NET, pour Silverlight, etc

Mais la raison de cette séparation n'est pas du tout le poids des DLL, c'est seulement pour limiter les dépendances. Par exemple si tu développes une appli pour ASP.NET, tu ne veux pas dépendre des assemblies WPF ou WinForms...

[cs_ntd]

Euuuuh je pense au contraire qu'il n'est chargé que ce qui est appellé dans le code.

Tout simplement parceque quand vous compilez en MSIL, il n'est fait référence qu'au fonctions utilisées...