Question

Mon fond est principalement en tant que Développeur Java, mais dernièrement, j'ai fait quelques travaux dans .NET.Donc, j'ai essayé de faire quelques projets simples à la maison pour apprendre à mieux travailler avec .NET.J'ai été en mesure de transférer une grande partie de mon Java de l'expérience dans le travail avec .NET (plus précisément, C#), mais la seule chose qui a vraiment perplexe moi est des espaces de noms.

Je sais que les espaces de noms sont similaires pour les packages Java, mais qu'à partir de ce que je peux dire, la principale différence est que, avec les packages Java ils utilisent de fichier réel les dossiers pour afficher la séparation, tandis que dans .NET, il ne le fait pas et tous les fichiers résident dans un même dossier et de l'espace de noms est tout simplement déclaré dans chaque classe.

Je trouve ça bizarre, parce que j'ai toujours vu des paquets comme un moyen d'organiser et de groupe de code, le rendant plus facile à naviguer et à comprendre.Depuis dans .NET, il ne fonctionne pas ce travail, de cette façon, les heures supplémentaires, le projet semble plus surpeuplées et pas aussi facile à naviguer.

Suis-je manqué quelque chose?Je dois être.Je devrais être de casser des choses dans des projets distincts au sein de la solution?Ou est-il une meilleure façon de garder les classes et les fichiers organisés au sein d'un projet?

Edit:Comme Blair l'a souligné c'est à peu près la même question posée ici.

Était-ce utile?

La solution

Je ne peux pas prétendre que c'est une bonne pratique, mais je vois souvent des fichiers organisés dans une hiérarchie de répertoires, qui correspond à l'espace de noms.Si cela correspond à votre modèle mental du code mieux, puis le faire - je ne peux pas penser à tout préjudice.Tout simplement parce que l' .NET modèle n'a pas d'imposer des relations entre les espaces de noms, des projets, et la structure de répertoire ne signifie pas que vous ne pouvez pas avoir de telles relations, si vous le souhaitez.

Je serais un peu réticent à l'idée de briser le code en plus de projets que vous avez besoin, ce qui peut ralentir la compilation et ajouter un peu de surcharge lorsque vous avez à gérer plusieurs assemblées.

EDIT:Notez que cette question est près du double de devrait les dossiers dans une solution de match de l'espace de noms?

Autres conseils

Yep, en .NET espace de noms ne dépend pas de système de fichier ou n'importe quoi d'autre.C'est un grand avantage, à mon avis.Par exemple, vous pouvez diviser votre code entre les différentes assemblées qui permet de flexible de distribution.

Lorsque vous travaillez dans Visual Studio, l'EDI tend à introduire de nouveaux noms lorsque vous ajoutez un nouveau dossier à l'arborescence du projet.

Voici un lien utile à partir de MSDN:

Espace De Noms De L'Intitulé

La règle générale pour nommer les espaces de noms est d'utiliser le nom de la société, suivie par la technologie de nom et éventuellement le fonctionnalité et design comme suit.
Nom de la société.TechnologyName[.Fonction][.Design]

Bien sûr, vous pouvez utiliser des espaces de noms dans la façon de trouver plus approprié.Toutefois, si vous allez partager votre code, je vous recommande d'aller avec les normes acceptées.

MODIFIER:

Je recommande fortement à tout .net développeur pour obtenir une copie de Cadre des lignes directrices de conception Ce livre vous aidera à comprendre comment et pourquoi .NET est conçu.

Un VS solution contient normalement un ou plusieurs projets.Thse projets ont de noms par défaut (généralement de l'espace de noms est juste le nom du projet).Normalement, si vous ajoutez un dossier dans le cadre du projet, toutes les classes seront nommés comme suit:

DefaultNamespace.FolderName.ClassName

Bien sûr, vous pouvez modifier l'espace de noms par défaut du projet, et d'avoir de vos classes être nommé de la manière que vous souhaitez.

Autant que quand/comment casser des trucs dans des projets, c'est une question d'expérience et/ou de préférence.Toutefois, vous devez absolument casser des trucs dans des projets au sein d'une solution, afin de garder votre projet organisé.Si la gestion de trop nombreuses assemblées devient lourd (comme Blair l'a suggéré), vous pouvez toujours ILMerge vos assemblées en une seule assemblée.Ce qui est formidable à propos de ILMerge est que même si vous vous retrouvez avec une seule assemblée, tous vos classes de garder leur origine des noms pleinement qualifiés.

Il est également important de se rappeler que VS solution n'a aucune incidence sur le code - ie.ils n'ont pas construit.VS Solutions ne sont rien, mais un moyen de projets de groupe;ce sont les projets qui sont construit et transformé en Dll.

Enfin, VS vous permet d'ajouter des dossiers "virtuels" n'importe où dans la solution.Ces dossiers ne sont pas associées à un dossier dans le système de fichiers, et sont utilisés uniquement comme un autre moyen pour vous aider à organiser vos projets et d'autres objets à l'intérieur de la solution.

Les espaces de noms sont un regroupement logique, alors que les projets sont un physique de regroupement.

Pourquoi est-ce important?Penser .NET 2.0, 3.0 et 3.5..NET 3.0 est fondamentalement .NET 2.0 avec un certain assemblées, et de 3,5 ajoute un peu plus d'assemblées.Ainsi, par exemple, .NET 3.5 ajoute l' DataPager de contrôle, qui est un contrôle web et devraient être regroupées dans System.Web.UI.WebControls.Si les espaces de noms et les emplacements physiques sont identiques, il ne pouvait pas parce qu'il est dans une autre assemblée.

Afin d'avoir des espaces de noms comme indépendante des entités logiques signifie que vous pouvez avoir des membres de plusieurs montages différents qui sont tous regroupés logiquement ensemble parce qu'ils sont destinés à être utilisés en conjonction les uns avec les autres.

(D'ailleurs, il n'y a rien de mal à avoir de vos capacités physiques et logiques mises en page sont assez similaires.)

En effet, l' .Net de l'environnement vous permet de lancer votre code à l'IDE/système de fichiers comme des spaghettis contre un mur.

Cela ne signifie pas que signifie cette approche est sain d'esprit, cependant.Ses généralement une bonne idée de coller avec le project.foldername.Class l'approche qui a été mentionné plus tôt.C'est aussi une très bonne idée de garder toutes les classes à partir d'un espace de noms dans la même classe.

En Java, vous pouvez le faire tordu choses comme de la "souplesse" que vous voulez, mais les outils ont tendance à fortement dissuader.Honnêtement, l'un des la plupart des choses confuses pour moi d'être introduit à la .Net monde était juste la façon bâclée/incompatible cela peut être fait grâce à la faible orientation.Il est facile d'organiser les choses sainement, avec un peu de réflexion, cependant.:)

la différence est que .net les espaces de noms n'avaient rien à voir avec java.

.net les espaces de noms sont purement pour la gestion déclarative portée, et n'ont rien à voir avec des dossiers, des projets ou de leurs lieux.

c'est très simple tout déclaré dans un espace de noms est accessible lorsque vous inclure une "aide" pour cet espace de noms.

très facile.

le choix de ce nom et si oui ou non/combien de '.' séparateurs que vous utilisez est entièrement à vous.

VS par défaut à ajouter .foldernames à vos espaces de noms juste pour essayer et être utile.

cet article explique les espaces de noms assez bien:http://www.blackwasp.co.uk/Namespaces.aspx

Il dispose également d'un exemple de convention de nommage, vers la fin, bien que votre nom de convention est à votre appel!;)

cela dit, la plupart des endroits où j'ai travaillé à et les gens avec qui j'ai travaillé de commencer avec le nom de l'entreprise qui est sensée, car il rend typenames pour que société distincte, (distincte de l'autre, les bibliothèques, les fournisseurs, open source projcts etc.)

Vous pouvez ajouter des dossiers à votre solution pour chaque espace de noms.Tout ça va encore compiler en un seul fichier exécutable, il organise vos fichiers source et donne (ce qui je pense est) l'effet désiré?

En général, je ajouter un dossier pour chaque espace de noms dans mon projet, et de les imbriquer, selon la même hiérarchie (MyApp.Vue.Les boîtes de dialogue par exemple)

Les espaces de noms sont purement sémantique.Alors que, généralement, ils reflètent une structure de dossiers, au moins lors de l'utilisation de l'IDE de Visual Studio, ils n'ont pas besoin.

Vous pouvez avoir le même espace de noms référencé dans plusieurs bibliothèques, laid mais c'est vrai.

J'ai toujours considéré le fichier source de l'organisation et de l'affectation des identifiants pour les classes et les objets à deux problèmes différents.J'ai tendance à tenir des cours en groupes, mais pas à chaque groupe doit être un espace de noms.Les espaces de noms existent (plus ou moins) pour résoudre le problème des conflits de nom—en plat-espace de noms de langages tels que le C, vous ne pouvez pas marcher à deux pieds sans trébucher sur les identificateurs comme mycompany_getcurrentdate ou MYCGetCurrentDate, parce que le risque d'un conflit avec une autre fonction dans une troisième partie (ou système) de la bibliothèque est beaucoup plus petit.Si vous avez créé un package ou d'un espace de noms pour chaque séparation logique, vous obtiendrez (exemple Java) de la classe des noms comme java.lang.primitivewrapper.numeric.Integer, qui est à peu près inutile.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top