Qual è l'impatto di avere spazi dei nomi in più DLL?

Question

Ho ereditato un progetto VB.net che genera 2 DLL: una per l'app Web e un'altra per il "livello aziendale". Questo è per una sub-app di un sito web più grande. (Utilizzando VS2005).

Il problema è che qualcosa non ha un buon odore con la DLL & amp; struttura dello spazio dei nomi e vorrei sapere se ci sono impatti sulle prestazioni.

L'app Web principale è " Foo " ;, e genera Foo.dll. Foo.dll contiene lo spazio dei nomi App.Foo, che contiene le classi per tutte le pagine, i controlli utente, ecc.

C'è anche un progetto " FooLib " che genera FooLib.dll. FooLib.dll contiene anche uno spazio dei nomi App.Foo, che contiene una serie di definizioni di classe. Esistono alcuni altri spazi dei nomi come App.Foo.Data, App.Foo.Logic, ecc.

C'è qualcosa di sbagliato in questo? In che modo il runtime trova una classe su più DLL?

Answer 1

Quando viene compilato il programma, viene incluso il nome completo del tipo insieme a "prove". Questa prova include il nome dell'assembly e le informazioni sulla versione. Altrimenti non saprebbe se si desidera la versione 1.0 o 1.1 o 2.0 della classe. Questo stesso sistema consente di trovare classi diverse nello stesso spazio dei nomi in assiemi diversi.

Per quanto riguarda le prestazioni, non c'è un effetto enorme. Sul lato positivo significa che alcune delle tue cose potrebbero essere caricate in momenti diversi e di solito è l'effetto desiderato.

Gli spazi dei nomi riguardano la funzionalità di packaging in un modo che lo rende facile da trovare. Gli assiemi riguardano la funzionalità di imballaggio in modo efficiente da caricare. A volte non sono uguali.

Answer 2

Non c'è niente di sbagliato in questo, l'unico problema possibile potrebbe essere che 1) gli sviluppatori vedano " App.Foo.Something " potrebbe non sapere quale assembly cercare in 2) se si utilizza lo stesso nome in entrambi, le app che si compilano (almeno in c #) riceveranno errori sui nomi di tipo ambigui.

Per quanto riguarda il runtime, i tipi sono specificati per assembly e name - lo spazio dei nomi è solo una parte del typename. Quindi il runtime non avrà problemi a trovare il tipo - quando si compilano le informazioni su quale assembly in cui trovarlo è compilato.

Answer 3

No, non c'è niente di sbagliato in questo.

Considera, io uso un numero di librerie di classi personalizzate e quasi ognuna di esse ha la seguente struttura dello spazio dei nomi:

  

.Web.UI.Controls.

Che è simile (e suggerito dagli Stati Uniti come best practice) a System.Web.UI.Controls ..

Il fatto è che il compilatore saprà che esiste lo spazio dei nomi giusto in tutte le DLL assegnate (lo cercherà in entrambe le DLL). L'unico motivo per cui esiterei a renderli esattamente uguali in questo modo è a causa della possibile confusione SVILUPPATORE . L'altro motivo è nel caso in cui ogni spazio dei nomi abbia una classe chiamata esattamente la stessa cosa - e questo genererà un errore del compilatore fino a quando non verrà risolto con una dichiarazione dello spazio dei nomi con nome completo.

Che è parte del motivo per cui è possibile Alias ??namespace. L'aliasing curerà entrambi i concetti. La struttura appare così:

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

Quindi, se poi hai una classe Bar sia in Foo.App.Foo che in FooLib.App.Foo, per accedere alla versione dell'applicazione dovresti usare:

bar x = new bar();

Per la versione della Libreria che useresti:

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

Answer 4

No, non c'è niente di sbagliato negli spazi dei nomi sovrapposti. Dai un'occhiata al framework .net stesso in cui sono sovrapposti molti spazi dei nomi.

Answer 5

Gli spazi dei nomi non sono presenti a livello di IL. Il runtime trova una classe da uno pseudo nome completo, ovvero il nome del tipo preceduto dal suo spazio dei nomi.

Non penso che ci sia un problema tecnico a farlo, infatti .NET Framework stesso a volte utilizza gli stessi spazi dei nomi in diversi assembly fisici.

I namespace non sono cittadini di prima classe nel mondo .NET e me ne pento.