Qual é o impacto de ter espaços para nome em várias DLLs?

Question

Eu herdei um projeto VB.net que gera 2 DLLS: uma para o aplicativo web, e outro para a "camada de negócios". Isto é para um sub-aplicativo de um site maior. (Usando VS2005).

O problema é que que algo não cheira bem com a estrutura DLL & namespace, e eu gostaria de saber se existem impactos no desempenho.

A principal aplicação web é "Foo", e gera Foo.dll. Foo.dll contém App.Foo namespace, que contém as classes para todas as páginas, controles de usuário, etc.

Há também um projeto "FooLib" que gera FooLib.dll. FooLib.dll também contém um namespace App.Foo, que contém um monte de definições de classe. Existem alguns outros namespaces como App.Foo.Data, App.Foo.Logic, etc.

Existe errado alguma coisa com isso? Como o tempo de execução encontrar uma classe em várias DLLs?

Answer 1

Quando o programa é compilado o nome do tipo completo está incluído junto com "evidência". Esta evidência inclui o nome da informação de montagem e controle de versão. Caso contrário, ele não saberia se você queria o 1.0 ou o 1.1 ou a versão 2.0 da classe. Este mesmo sistema permite-lo para encontrar classes diferentes no mesmo espaço de nomes em diferentes montagens.

Tanto quanto o desempenho vai, não há um enorme efeito. No lado benéfico isso significa que algumas de suas coisas poderiam ser carregados em diferentes momentos e isso é normalmente o efeito desejado.

Namespaces está prestes embalagem funcionalidade de uma forma que torna mais fácil de encontrar. Montagens são sobre embalagens funcionalidade de uma forma que é eficaz para carregar. Às vezes, eles não são o mesmo.

Answer 2

Não há nada de errado com isso, as únicas possíveis problemas pode ser que 1) os desenvolvedores vendo "App.Foo.Something" pode não saber que a montagem para olhar nos 2) se o mesmo nome é usado em ambos, os aplicativos compilar contra ( em c # pelo menos) vai ter erros sobre nomes de tipos ambíguos.

Quanto ao tempo de execução, tipos são especificados pela montagem e nome - o namespace é apenas parte do typename. Assim, o tempo de execução não terá nenhum problema encontrar o tipo -. Quando você compilar as informações sobre o conjunto de encontrá-lo em é compilado em

Answer 3

Não, não há nada de errado com isso.

Considere, eu uso uma série de bibliotecas de classe costume, e quase cada um deles tem a seguinte estrutura namespace:

.Web.UI.Controls.

O que é semelhante (e sugerido pelo MS como melhores práticas) para System.Web.UI.Controls ..

A coisa é que o compilador sabe que há o namespace certo em tantos DLLs como você atribuir (ele irá procurá-lo em ambas as DLLs). A única razão que eu hesite em fazer-lhes exatamente o mesmo, desta forma é devido a possíveis Desenvolvedor confusão. A outra razão é no caso de cada namespace tem uma classe chamada exatamente a mesma coisa -. E isso vai lançar um erro compilador até que seja resolvido com uma declaração Namespace totalmente chamado

O que é parte da razão pela qual você pode namespaces Alias. Aliasing vai curar ambos os conceitos. A estrutura para ele se parece com isso:

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

Então, se você, em seguida, ter uma classe Bar, tanto Foo.App.Foo e FooLib.App.Foo, para acessar a versão do aplicativo que você usaria:

bar x = new bar();

Para a versão Biblioteca você usaria:

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

Answer 4

Não há nada de errado com namespaces sobrepostos. Dê uma olhada no próprio framework .NET onde muitos namespaces são sobrepostos.

Answer 5

Os espaços de nomes não estão presentes no nível do IL. O tempo de execução encontrar uma classe a partir de uma pseudo nome totalmente qualificado, isto é, o nome do tipo prefixado pelo seu namespace.

Eu não acho que há um problema técnico para fazer isso, de fato, o .NET Framework em si às vezes usa mesmos namespaces atravessando várias montagens físicas.

Namespace não são de primeira classe cidadão no mundo da NET, e eu lamento isso.