Quel est l'impact d'avoir des espaces de noms dans plusieurs DLL?

Question

J'ai hérité d'un projet VB.net générant 2 DLL: une pour l'application Web et une autre pour la "couche métier". Ceci est pour une sous-application d'un site web plus grand. (Utilisation de VS2005).

Le problème est que quelque chose ne va pas avec la DLL & amp; la structure de l'espace de noms, et j'aimerais savoir s'il y a des impacts sur les performances.

L’application Web principale est "Foo", et génère Foo.dll. Foo.dll contient l'espace de noms App.Foo, qui contient les classes pour toutes les pages, contrôles utilisateur, etc.

Il existe également un projet "FooLib". qui génère FooLib.dll. FooLib.dll contient également un espace de noms App.Foo, qui contient un ensemble de définitions de classe. Il existe quelques autres espaces de noms tels que App.Foo.Data, App.Foo.Logic, etc.

Quelque chose ne va pas avec ça? Comment le moteur d'exécution trouve-t-il une classe sur plusieurs DLL?

Answer 1

Lorsque votre programme est compilé, le nom de type complet est inclus avec "preuve". Cette preuve inclut le nom de l'assembly et les informations de version. Sinon, vous ne sauriez pas si vous voulez la version 1.0, la version 1.1 ou la version 2.0 de la classe. Ce même système lui permet de trouver différentes classes dans le même espace de noms dans différents assemblys.

En ce qui concerne les performances, l’effet n’est pas énorme. Du côté des avantages, cela signifie que certaines de vos affaires pourraient être chargées à des moments différents, ce qui correspond généralement à l’effet souhaité.

Les espaces de noms traitent des fonctionnalités de packaging de manière à faciliter leur recherche. Les assemblages concernent l’emballage des fonctionnalités de manière efficace. Parfois, ils ne sont pas les mêmes.

Answer 2

Il n'y a rien de mal à cela, les seuls problèmes possibles sont peut-être 1) les développeurs qui voient "App.Foo.Something". 2) si le même nom est utilisé dans les deux applications, les applications compilant contre (en c # au moins) obtiendront des erreurs à propos des noms de type ambigus.

Comme pour l'exécution, les types sont spécifiés par assembly et name - l'espace de nom fait simplement partie du nom de type. Ainsi, le moteur d'exécution n'aura aucun problème à trouver le type - lorsque vous compilez les informations sur l'assembly dans lequel le trouver, est compilé.

Answer 3

Non, il n’ya rien de mal à cela.

Considérez que j'utilise un certain nombre de bibliothèques de classes personnalisées et que la plupart d'entre elles possèdent la structure d'espace de noms suivante:

  

.Web.UI.Controls.

Qui est similaire (et suggéré par MS comme meilleure pratique) à System.Web.UI.Controls ..

Le truc, c'est que le compilateur saura qu'il y a le bon espace de noms dans autant de DLL que vous en affectez (il le recherchera dans les deux DLL). La seule raison pour laquelle j’aimerais hésiter à leur donner exactement la même chose de cette façon est due à une possible confusion DÉVELOPPEUR . L'autre raison est le cas où chaque espace de nom a une classe nommée exactement la même chose, ce qui déclenchera une erreur du compilateur jusqu'à ce qu'elle soit résolue avec une déclaration d'espace de nom entièrement nommée.

Ce qui explique en partie pourquoi vous pouvez utiliser les espaces de noms Alias. L'aliasing va guérir les deux concepts. La structure pour cela ressemble à ceci:

using Foo.App.Foo;
using FooLib = FooLib.App.Foo;

Ainsi, si vous avez ensuite une classe Bar dans Foo.App.Foo et FooLib.App.Foo, pour accéder à la version de l'application, utilisez:

bar x = new bar();

Pour la version de la bibliothèque que vous utiliseriez:

FooLib.bar x = new FooLib.bar();

Answer 4

Non, il n'y a rien de mal avec les espaces de noms superposés. Jetez un coup d’œil au framework .net lui-même où de nombreux espaces de noms sont superposés.

Answer 5

Les espaces de noms ne sont pas présents au niveau IL. Le moteur d’exécution recherche une classe à partir d’un pseudo nom pleinement qualifié, c’est-à-dire le nom du type préfixé par son espace de nom.

Je ne pense pas qu'il y ait un problème technique à cela. En fait, le .NET Framework lui-même utilise parfois les mêmes espaces de noms pour plusieurs assemblys physiques.

Les espaces de noms ne sont pas des citoyens de première classe dans le monde .NET, et je le regrette.