¿Cuál es el impacto de tener espacios de nombres en varias DLL?

Question

He heredado un proyecto VB.net que genera 2 DLLS: uno para la aplicación web y otro para la "capa empresarial". Esto es para una sub-aplicación de un sitio web más grande. (Utilizando VS2005).

El problema es que algo no huele bien con la DLL & amp; estructura del espacio de nombres, y me gustaría saber si hay algún impacto en el rendimiento.

La aplicación web principal es " Foo " ;, y genera Foo.dll. Foo.dll contiene el espacio de nombres App.Foo, que contiene las clases para todas las páginas, controles de usuario, etc.

También hay un proyecto "FooLib" que genera FooLib.dll. FooLib.dll también contiene un espacio de nombres App.Foo, que contiene un montón de definiciones de clase. Hay algunos otros espacios de nombres como App.Foo.Data, App.Foo.Logic, etc.

¿Hay algo malo en esto? ¿Cómo encuentra el tiempo de ejecución una clase en varias DLL?

Answer 1

Cuando se compila su programa, se incluye el nombre completo del tipo junto con " evidencia " ;. Esta evidencia incluye el nombre del ensamblaje y la información de versiones. De lo contrario, no sabría si quisieras la versión 1.0 o la versión 1.1 o 2.0 de la clase. Este mismo sistema le permite encontrar diferentes clases en el mismo espacio de nombres en diferentes ensamblajes.

En lo que respecta al rendimiento, no hay un gran efecto. En el lado beneficioso, significa que algunas de sus cosas podrían cargarse en diferentes momentos y ese suele ser el efecto deseado.

Los espacios de nombres se tratan de empaquetar la funcionalidad de manera que sea fácil de encontrar. Los ensamblajes tratan sobre la funcionalidad de empaquetado de una manera que es eficiente de cargar. A veces no son lo mismo.

Answer 2

No hay nada de malo en esto, los únicos problemas posibles pueden ser que 1) los desarrolladores vean '' App.Foo.Something '' puede que no sepa qué conjunto buscar en 2) si se usa el mismo nombre en ambos, las aplicaciones que compilan (al menos en c #) obtendrán errores sobre los nombres de tipo ambiguos.

En cuanto al tiempo de ejecución, los tipos se especifican por ensamblado y nombre: el espacio de nombres es solo parte del nombre de tipo. Por lo tanto, el tiempo de ejecución no tendrá problemas para encontrar el tipo, cuando compila la información sobre en qué ensamblado se encuentra.

Answer 3

No, no hay nada de malo en esto.

Considere que uso varias bibliotecas de clases personalizadas, y casi todas tienen la siguiente estructura de espacio de nombres:

  

.Web.UI.Controls.

Que es similar (y sugerido por MS como mejor práctica) a System.Web.UI.Controls ..

Lo que pasa es que el compilador sabrá que existe el espacio de nombres correcto en la cantidad de archivos DLL que asigne (lo buscará en ambos archivos DLL). La única razón por la que dudaría en hacerlos exactamente iguales es por la posible confusión DESARROLLADOR . La otra razón es en caso de que cada espacio de nombres tenga una clase llamada exactamente igual, y esto arrojará un error del compilador hasta que se resuelva con una declaración de espacio de nombres completamente nombrada.

Lo cual es parte de la razón por la que puedes alias espacios de nombres. El alias curará ambos conceptos. La estructura se ve así:

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

Entonces, si tiene una clase Bar en Foo.App.Foo y FooLib.App.Foo, para acceder a la versión de la aplicación usaría:

bar x = new bar();

Para la versión de la Biblioteca que usarías:

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

Answer 4

No, no hay nada de malo en los espacios de nombres superpuestos. Eche un vistazo al marco .net en sí, donde se superponen muchos espacios de nombres.

Answer 5

Los espacios de nombres no están presentes en el nivel de IL. El tiempo de ejecución encuentra una clase de un nombre pseudo totalmente calificado, es decir, el nombre del tipo prefijado por su espacio de nombres.

No creo que haya un problema técnico para hacerlo, de hecho, .NET Framework a veces usa los mismos espacios de nombres en varios ensamblajes físicos.

Los espacios de nombres no son ciudadanos de primera clase en el mundo .NET, y lo lamento.