Schéma d'une solution .NET

[Invité Patrick]

Existe-t-il un schéma présentant l'arborescence d'une solution .NET montrant ce qu'est une solution, un projet, une classe, un module, une procédure, une fonction, etc... (pas trouvé sur Google)

[(gile)]

Salut,

 

Je vais essayer de répondre parce que je ne pense pas que ça existe.

D'après ce que j'ai compris, ou cru comprendre, on ne peut pas vraiment parler d'arborescence dans la mesure où il s'agit de choses qui ne sont pas nécessairement liées hiérarchiquement même si on peut voir les unes comme "appartenant" aux autres.

 

Solution et projet sont des notions qui relèvent uniquement de l'environnement de développement (Visual Studio).

Une solution Visual Studio est un ensemble de paramètres de configuration concernant la génération d'un ou plusieurs projets Visual Studio (on peut le voir en ouvrant un fichier .sln avec un éditeur de texte).

On ne peut ouvrir qu'une seule solution à la fois dans une session Visual Studio. Générer la solution (F6) génère tous les projets qu'elle contient.

Si une solution contient plusieurs projets, un seul peut être défini comme projet de démarrage (en général l'application) les autres étant souvent des bibliothèques spécifiques aux quelles l'application fait référence.

Chaque projet peut être écrit dans un langage différent mais tout le code écrit dans un projet doit l'être dans le même langage. Par exemple, on peut avoir, dans la même solution, un projet de démarrage dont le code est écrit en C# et d'autres projets bibliothèques écrits en F# ou VB.

 

Un projet réuni un ensemble de fichiers (fichiers source, ressources, etc.) qui seront compilés en un unique assemblage (assembly) dll ou exe. Les paramètres de configuration de la compilation sont définis dans un fichier xml : le fichier .csproj, .fsproj ou .vbproj suivant le langage utilisé.

 

On peut donc voir là une arborescence :

Une solution contient un ou des projets qui contiennent un ou des fichiers

 

Mais tout ceci est donc bien spécifique à Visual Studio (ou à un autre IDE) car on peut très bien, si on est un peu maso, écrire les fichiers source dans le bloc-note et compiler un exe ou une dll .NET en ligne de commande...

 

Et il n'y a pas de lien direct avec les autres notions : espaces de noms, classes, etc. qui sont spécifiques à la structure .NET et au langage utilisé.

Même s'il est recommandé de créer un fichier par classe, ce n'est pas une obligation. Plusieurs classes peuvent être définies dans un seul fichier. Une classe peut être définie à l'intérieur d'une autre (imbriquée). Une classe peut même être définie dans deux (ou plus) fichiers différents (classes partielles), c'est ce que fait Visual Studio en générant automatiquement le code de description des formulaires dans le fichier .designer.cs ou designer.vb.

Un projet, comme un fichier, peut définir plusieurs namespaces et le même namespace est souvent utilisé dans plusieurs fichiers d'un même projet.

 

Un espace de nom (namespace) sert essentiellement à éviter les conflits de noms. On peut le voir comme un préfixe ou un chemin. Par exemple les types Application suivants sont bien deux types différents :

System.Windows.Forms.Application
Autodesk.AutoCAD.Application

Il est tout à fait possible, mais peu recommandé, de définir des types hors d'un espace de nom (ils sont alors dans l'espace de nom global).

Donc, généralement, c'est à l'intérieur d'un namespace qu'est écrit le code .NET.

 

Les classes (ainsi que les structures et les modules VB) définissent des types. Le type est une notion essentielle de la Programmation Orientée Objet. Un type décrit la structure d'un objet à l'aide membres : les champs, propriétés, méthodes et évènements. En POO, un objet est une instance d'un type.

Avec C#, où la POO est omniprésente, on ne peut écrire de code en dehors d'une classe.

Avec VB on peut aussi utiliser des modules pour définir des types, dans ce cas on peut accéder aux membres du module sans référence explicite au type (ou pourrait parler de membres globaux pour l'assemblage).

Avec F#, qui privilégie la programmation fonctionnelle, le module est plus proche de l'espace de nom.

 

Les membres d'une classe ou d'une structure sont définis en son sein.

Les champs sont des sortes de variable globales à la classe, pour respecter l'encapsulation, ils sont généralement privés (donc inaccessibles directement pour les instances de la classe).

Les constructeurs et les propriétés dont de méthodes particulières.

Les premières servent à créer une instance avec ou sans argument (souvent elles ne font qu'initialiser les champs)

Les secondes permettent l'accès et/ou la modification des valeurs de ces champs.

Les méthodes proprement dites définissent des actions.

En VB on a coutume de séparer les procédures sans valeur de retour (Sub) et les fonctions (Function) qui retournent une valeur.

En C# on remplace simplement le type de valeur de retour des méthodes qui ne retourne rien par le mot clé void.

En F#, bien sûr on ne parle que de fonctions même si elle peuvent retourner le type unit : () c'est à dire rien.

Les évènements servent à signaler au programme que, justement, un évènement s'est produit dans un objet.

 

Là encore on peut voir une arborescence : un espace de nom contient une ou plusieurs classes et/ou structures (et/ou modules en VB) qui peuvent contenir des champs, des propriétés, des méthodes, des évènements.

[Invité Patrick]

Merci pour cette très complète explication. Voici un schéma simplifié qui pourra être utile aux débutants:

 

http://www.exmateria.com/images/visual-studio.png

[Invité Patrick]

Une classe peut même être définie dans deux (ou plus) fichiers différents (classes partielles), c'est ce que fait Visual Studio en générant automatiquement le code de description des formulaires dans le fichier .designer.cs ou designer.vb.

 

Oui je trouve cela pratique par rapport au VBA par exemple où le code des formulaires "mélange" le fonctionnement des contrôles du formulaire et le code tapé par le programmeur pour exécuter des actions en fonction des contrôles. A ce propos, y a-t-il moyen de "verrouiller" la classe partielle .designer.cs de façon à ne pas par erreur la modifier puisqu'en principe elle ne doit pas l'être?

[(gile)]

Pas à ma connaissance, mais pour modifier cette classe, il faut d'abord l'ouvrir et elle n'est pas accessible directement (sous nœud de Form1.cs), de plus elle contient un avertissement en commentaire :

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

 

Il est malgré tout parfois pratique de pouvoir y accéder quand par exemple on a supprimé un traitement d'évènement à une action sur un contrôle (Button1) ce qui provoque une erreur à la compilation :

Form1 ne contient pas de définition pour 'Button1_Click' ...

Il suffit alors de double cliquer sur cet avertissement (dans la fenêtre 'Liste d'erreurs') pour que visual Studio ouvre le fichier Form1.designer.cs sur l'erreur en question, on peut alors aisément supprimer cette ligne.

[(gile)]

Juste quelques petites remarques sur ton schéma :

- on dirait que les méthodes peuvent contenir des procédures et des fonctions (or procédures et fonctions ne sont que des types de méthodes et seul VB fait vraiment la distinction entre les deux)

- une classe peut aussi contenir un ou des constructeurs (et parfois un destructeur)

- une classe peut aussi contenir d'autres classes (ou structures).

- au même niveau que les classes, un projet peut aussi contenir des structures (classes "allégées") et des interfaces (contrat à remplir pour les classes dérivées).