J'ai une question rapide ici. J'ai une assemblée réutilisée par quelques développeurs contenant divers bits de fonctionnalité, mais il est techniquement divisé dans divers espaces de noms représentant des blocs logiques de fonctionnalité.
Maintenant, il est proposé avec aussi peu d'espaces de noms publics que possible. Fondamentalement, l'utilisateur ne devrait pas savoir (et ne sait pas actuellement) quelle structure interne est utilisée pour la classe qu'ils tentent d'utiliser.
Disons que vous avez ceci:
ns1
ns2
Fondamentalement, les utilisateurs savent qu'ils utilisent l'imageName.ns1 pour la fonctionnalité générale concernant NS1. Maintenant, dans cet exemple simple, j'ai mis une classe contenant des méthodes d'extension dans des extensions d'espace de sous-noms, donc essentiellement si un utilisateur final tente d'utiliser l'Assemblée, il devait connaître la structure interne de la DLL pour connaître l'extension existante (C'est l'un de ces exemples où Intellisense ne vous dit pas que vous savez).
So Bottom Line ... en ce moment, j'ai cette assemblée et interne (le projet VS), je divisez le projet en dossiers logiques comme on le ferait normalement, mais je ne laisse pas les espaces de noms à suivre les dossiers. De cette façon, l'Assemblée est divulguée dans des blocs logiques que les utilisateurs connaissent sans connaître les structures internes et n'ont pas besoin de savoir qu'il pourrait y avoir des espaces de noms séparés pour des extensions, etc.
Maintenant, personnellement, j'aimerais que je sache si je pouvais laisser mes espaces de noms de mon code suivez ma structure de dossiers, mais carapez en quelque sorte ces espaces de sous-noms à l'espace de noms principal à la compilation.
est-il possible d'une manière d'une manière ou d'une autre d'atteindre cette «redirection» comme vous le ferez?
Pour le mettre simplement, je veux pouvoir adresser Ns1.ns11.class111 publiquement comme ns1.class111 en dehors de l'assemblage tout en conservant une structure appropriée à l'intérieur de l'assemblage.
3 Réponses :
Si vous devez fournir un accès à 3ème partie à un code interne via différents espaces de noms, je vais résumer l'accès aux données dans un assemblage distinct (qui dépend de l'original) ou d'utiliser un service Web pour offrir au sous-ensemble. de fonctionnalité que vous voulez qu'ils accèdent.
Vous pourrez peut-être faire quelque chose avec des attributs sur chacune de vos classes, même si j'imagine que cela deviendrait assez désordonné, assez rapidement.
Il y a quelques façons de penser à cela. Venir d'un fond vb.net à l'origine et c # Plus récemment, j'ai les commentaires suivants sur le sujet.
Personnellement, j'ai travaillé avec une équipe qui a importé tout le code source sous-jacent pour tout ce qu'ils ont référencé dans son logiciel d'entreprise, ils pourraient donc "changer". À la fin de la journée, il a créé un niveau impie de complexité de la construction et a effrayé le pantalon de moi lors du débogage. Nuget fournit un modèle très populaire et très populaire, celui que j'ai adopté pour le code "partagé" d'entreprise. Si j'ai besoin de "Tweek" du code partagé, je le fais dans la solution / projet séparément, testez-le, déployez-le et utilisez le contrôle de source ou Nugget pour copier les fichiers.
Voici une idée: Créez Cours d'emballage pour le public fort>. Il peut être un peu inefficace (bien que JIT puisse s'en occuper) et relativement un peu plus difficile à entretenir, mais si vous êtes inquiet de vos API publiques (que vous devriez être), cela pourrait être une bonne option. Enchaînant quelques appels ne sera pas une préoccupation dans la plupart des cas et vous auriez un calque concerné par l'API publique, vous permettant potentiellement de commettre quelques péchés derrière votre façade (enfreindre de bonnes règles de conception logicielles pour le des performances par exemple) Vous pouvez créer votre structure interne, mais vous aimez: p> .. puis créez une emballeuse publique pour la fonctionnalité interne avec les espaces de noms que vous souhaitez Exposer: P> namespace Framework.Cool
{
public class Beans
{
// omitted code for brevity
public bool Cook()
{
return _beansWeWantToCook.Cook();
}
}
}
Question interessante. Un type ne peut vivre que dans un espace de noms. Si vous modifiez
ns1.ns11.class111 surns1.class111 à (PRE) compilent l'heure, vous devrez également modifier toutes les références, comme existant (test) Le code s'attendra à ce qu'il soit dansns1.ns11 .Ma pensée personnelle est pourquoi n'utiliseriez-vous pas les mêmes espaces de noms en interne à l'extérieur? S'ils sont déroutants à une personne externe, alors pourquoi pas à une personne interne?
Ce n'est pas qu'ils sont déroutants. C'est juste que l'utilisateur final ne devrait pas avoir à connaître la structure interne pour pouvoir accomplir leurs tâches. Disons que vous avez une espace de noms d'utilitaires interne, qui contient, par exemple une classe de "crypter ', mais que vous souhaitez que votre utilisateur ait accès à tous vos services publics sans avoir à savoir qu'elle est considérée comme une utilité à l'intérieur de l'Assemblée.
Putain, les commentaires sont courts. :-) identre pour les classes d'extension et les classes d'exception personnalisées, vous souhaitez que votre utilisateur final ait accès aux classes disponibles dans la DLL sans manuellement à ne pas oublier d'ajouter l'espace de noms interne personnalisé. Importation de l'espace de noms de base.
Une mauvaise idée. Le code doit être dans 1 espace de noms uniquement, alors faites le choix. Lorsque vous ne voulez pas suivre la structure du dossier (juste une défaillance de VS sensible), ne l'utilisez pas. Mais ne le changez pas lors de la compilation (publier). Cela briserait tant de choses.