Discussion :

[ced600]

Nop un namespace n'est pas un package java.
Pour un modèle MVC pas besoins de plusieurs projets non plus. Mais ce serait plus juste de découpé chaque couche en projet plutot qu'en namspace.
Bah en général je fait :
Vue = Un projet.
MC = un projet. où je sépare bien d'un poinst de vue composant dans mon archi le M et le C.
Enfin je fait ainsi par ce que l'accés à mes données est simple.
Donc si tu veux bien découper en MVC, alors faut faire trois projets.
Mais dans ce cas là tes classes assurant la liaison entres la vue le controleur et le modèle sont des classes de type interfaces. Donc utilise plutot les interfaces, ce sera moins galère.

Un gros projet s'appelle une solution

Avec les bonne dénomination tout est plus clair.

1 Solution -> plusieurs projet -> un namespace par projet -> 1 ou plusieurs classes par projet.

En général c'est comme cela.

[Bluedeep]

.
Je crois que un projet en C# correspond à un package Java.

Non. L'équivalent d'un package java est une assembly en .Net. La notion de projet est orienté IDE (même si dans la pratique, un projet = assembly, mais il y a des exceptions). Néanmoins un assembly peut exposer autant d'espace de nom qu'il veut (contrairement à Java il me semble) et un espace de nom donné peut être étendu sur plusieurs assembly.

J'ai un projet, trois espaces de noms (model, vue, controller). Ensuite ma couche model est divisée en plusieurs sous packages. Avec à la racine de model une abstract factory in stanciant les objets de mes sous couches.
En .Net, faut-il faire trois projet (Model, Vue, Controleur) dans un même gros projet (Application).
Promis, après ça je me tais...

Par obligatoirement, tu peux en mettre trois, un seul ou quarante deux mille huit (un espace de nom peut inclure plusieurs projet/assembly et l'inverses est vrai aussi). L'Espace de nom a pour finalité d'offrir une arborescence de présentation des classes, qui n'est absolument pas lié à l'arborescence d'héritage des dites classes.

Par exemple, imaginons que j'ai deux espaces de noms :

- MyNameSpace
- MyNameSpace.MySubnameSpace

Je peux avoir un projet qui implémente des classes dans MyNameSpace, un autre qui en implémente dans MyNameSpace et dans MyNameSpace.MySubnameSpace, et un autre dans MySubnameSpace uniquement si je le désire.

Maintenat imaginons que j'ai une classe A dans MyNameSpace.MySubnameSpace, rien ne m'empêche de créer une classe B qui hértite de A dans MyNameSpace : il n'y a aucun lien entre les namespace et l'héritage des classes.

[ced600]

Oui c'est sur, mais je pense qu'il reste moins galère de faire un namespace par projet.
Sinon après faut bien maitriser ce que l'on fait, sinon c'est vite galère.

[Chubyone]

1 solution contient un ou plusieurs projet, qui sont au final des assembly : c'est le découpage "physique" de ton application.

Les namespace sont purement sémantique.

Tu peux avoir 2 projets Winforms différents (deux applications différentes) et un projet dll de User/CustomControls référencé par les 2 projets (ils utilisent les meme UserControls propre à ton appli)
Ils peuvent pourtant tous travailler sous le meme namespace : View.

[dahtah]

Mais dans ce cas là tes classes assurant la liaison entres la vue le controleur et le modèle sont des classes de type interfaces. Donc utilise plutot les interfaces, ce sera moins galère.

Déjà fait,

Un gros projet s'appelle une solution

Avec les bonne dénomination tout est plus clair.

1 Solution -> plusieurs projet -> un namespace par projet -> 1 ou plusieurs classes par projet.

En général c'est comme cela.

Ok, merci,
Mais d'après ce que disait Chubyone :

En fait le namespace est un niveau d'abstraction et de découpage au dessus de l'assembly : 2 projet peuvent travailler dans un seul meme namespace...

1 solution -> plusieurs namespace -> plusieurs projets par namespace.

[Chubyone]

Déjà fait,

Ok, merci,
Mais d'après ce que disait Chubyone :

1 solution -> plusieurs namespace -> plusieurs projets par namespace.

En fait la Solution est juste une organisation de tes projets : tu peux très bien avoir autant de solution que de projets et référencés les dll à la mano

[ced600]

En fait je dirais qu'il faut oublier le namespace, il pourrait ce placer n'importe où
En fait c'est :
1 solution -> 1 ou x projets

Et tu peux placer le namespace où tu veux.
Quand tu regardes les namespaces de ms tu peux voir :
System.Collections.Specialized;
Collections contiens des piles, des arraylist, et des interfaces.
Spécialized contiens des collections spécialisé qui implémentent les interfaces de Collections.
Et à vérifier, mais is je ne me trompe pas Collections et Spécialized sont des namespaces et pas des objets de Systems.
Enfin j'ai jamais eu l'idée de créer une instance de Spécialized

PS : Je suis en framework 1.1, en 2.0 tu ne trouves plus la même organisation.

[dahtah]

Et tu peux placer le namespace où tu veux.
Quand tu regardes les namespaces de ms tu peux voir :
System.Collections.Specialized;
Collections contiens des piles, des arraylist, et des interfaces.
Spécialized contiens des collections spécialisé qui implémentent les interfaces de Collections.
Et à vérifier, mais is je ne me trompe pas Collections et Spécialized sont des namespaces et pas des objets de Systems.
Enfin j'ai jamais eu l'idée de créer une instance de Spécialized

PS : Je suis en framework 1.1, en 2.0 tu ne trouves plus la même organisation.

Exemple interessant, je vais regarder.
Un grand merci à tous.