Espaços para nome .NET

Question

Minha formação é principalmente como desenvolvedor Java, mas ultimamente tenho feito alguns trabalhos em .NET.Então, tenho tentado fazer alguns projetos simples em casa para melhorar o trabalho com .NET.Consegui transferir grande parte da minha experiência em Java para trabalhar com .NET (especificamente C#), mas a única coisa que realmente me deixou perplexo foram os namespaces.

Eu sei que os namespaces são semelhantes aos pacotes Java, mas pelo que posso dizer, a principal diferença é que com os pacotes Java eles usam pastas de arquivos reais para mostrar a separação, enquanto no .NET isso não acontece e todos os arquivos residem em uma única pasta e o namespace é simplesmente declarado em cada classe.

Acho isso estranho, pois sempre vi os pacotes como uma forma de organizar e agrupar códigos relacionados, facilitando a navegação e a compreensão.Como no .NET não funciona dessa forma, com o passar do tempo, o projeto parece mais superlotado e não tão fácil de navegar.

Estou faltando alguma coisa aqui?Eu tenho que ser.Devo dividir as coisas em projetos separados dentro da solução?Ou existe uma maneira melhor de manter as classes e arquivos organizados dentro de um projeto?

Editar:Como Blair apontou, esta é praticamente a mesma pergunta feita aqui.

Answer 1

Não posso afirmar que seja uma prática recomendada, mas muitas vezes vejo arquivos organizados em uma hierarquia de diretórios que reflete o namespace.Se ele se ajusta melhor ao seu modelo mental de código, faça-o - não consigo pensar em nenhum mal.Só porque o modelo .NET não impõe relacionamentos entre namespaces, projetos e estrutura de diretórios, não significa que você não possa ter tais relacionamentos, se desejar.

Eu ficaria um pouco desconfiado em dividir o código em mais projetos do que você precisa, pois isso pode retardar a compilação e adicionar um pouco de sobrecarga quando você precisar gerenciar vários assemblies.

EDITAR:Observe que esta questão é quase uma duplicata de as pastas em uma solução devem corresponder ao namespace?

Answer 2

Sim, no namespace .NET não depende do sistema de arquivos ou de qualquer outra coisa.É uma grande vantagem na minha opinião.Por exemplo, você pode dividir seu código em diferentes assemblies, o que permite uma distribuição flexível.

Ao trabalhar no Visual Studio, o IDE tende a introduzir um novo namespace quando você adiciona uma nova pasta à árvore do projeto.

Aqui está um link útil do MSDN:

Diretrizes para nomenclatura de namespace

A regra geral para nomear namespaces é usar o nome da empresa seguido pelo nome da tecnologia e, opcionalmente, o recurso e o design da seguinte forma.
NomedaEmpresa.NomedaTecnologia[.Recurso][.Design]

É claro que você pode usar namespaces da maneira que achar mais adequada.No entanto, se você for compartilhar seu código, recomendo seguir os padrões aceitos.

EDITAR:

Eu recomendo fortemente a qualquer desenvolvedor .net que obtenha uma cópia do Diretrizes de design de estrutura Este livro irá ajudá-lo a entender como e por que .NET foi projetado.

Answer 3

Uma solução VS normalmente contém um ou mais projetos.Esses projetos possuem namespaces padrão (geralmente o namespace é apenas o nome do projeto).Normalmente, se você adicionar uma pasta dentro do projeto, todas as classes nela contidas serão nomeadas da seguinte forma:

DefaultNamespace.FolderName.ClassName

Claro, você pode alterar o namespace padrão do projeto e fazer com que suas classes sejam nomeadas da maneira que desejar.

Quanto a quando/como dividir as coisas em projetos, é uma questão de experiência e/ou preferência.No entanto, você deve absolutamente dividir as coisas em projetos dentro de uma solução, para manter seu projeto organizado.Se gerenciar muitas montagens se tornar complicado (como sugeriu Blair), você sempre pode ILMerge suas montagens em uma única montagem.O que é ótimo no ILMerge é que mesmo que você acabe com apenas um assembly, todas as suas classes mantêm seus nomes originais totalmente qualificados.

Também é importante lembrar que uma solução VS não tem relação com o código - ou seja.eles não são construídos.As soluções VS nada mais são do que uma forma de agrupar projetos;são os projetos que são construídos e transformados em DLLs.

Finalmente, o VS permite adicionar pastas "virtuais" em qualquer lugar da solução.Essas pastas não são mapeadas para uma pasta no sistema de arquivos e são usadas apenas como outro meio para ajudá-lo a organizar seus projetos e outros artefatos na solução.

Answer 4

Namespaces são um agrupamento lógico, enquanto os projetos são um agrupamento físico.

Por que isso é importante?Pense no .NET 2.0, 3.0 e 3.5.O .NET 3.0 é basicamente o .NET 2.0 com alguns assemblies extras, e o 3.5 adiciona mais alguns assemblies.Por exemplo, o .NET 3.5 adiciona o DataPager controle, que é um controle da web e deve ser agrupado em System.Web.UI.WebControls.Se os namespaces e os locais físicos fossem idênticos, não poderia ser porque estão em um assembly diferente.

Portanto, ter namespaces como entidades lógicas independentes significa que você pode ter membros de vários assemblies diferentes, todos agrupados logicamente porque devem ser usados ​​em conjunto.

(Além disso, não há nada de errado em ter layouts físicos e lógicos bastante semelhantes.)

Answer 5

Na verdade, o ambiente .Net permite que você jogue seu código no IDE/sistema de arquivos como um espaguete contra a parede.

Isso não significa que essa abordagem seja sensata, no entanto.Geralmente, é uma boa ideia seguir a abordagem project.foldername.Class mencionada anteriormente.Também é uma boa ideia manter todas as classes de um namespace na mesma classe.

Em Java, você também pode fazer coisas complicadas como essa, obtendo toda a "flexibilidade" desejada, mas as ferramentas tendem a desencorajá-lo fortemente.Honestamente, uma das coisas mais confusas para mim ao ser apresentado ao mundo .Net foi o quão desleixado/inconsistente isso pode ser graças à orientação relativamente pobre.No entanto, é fácil organizar as coisas de maneira sã, com um pouco de reflexão.:)

Answer 6

a diferença é que os namespaces .net não têm muito a ver com pacotes java.

Os namespaces .net servem exclusivamente para gerenciar o escopo declarativo e não têm nada a ver com arquivos, projetos ou suas localizações.

É muito simples tudo declarado em um espaço de nome específico é acessível quando você inclui um 'usando' nesse espaço para nome.

muito fácil.

A escolha do nome e se/não/quantos separadores você usa depende inteiramente de você.

O padrão do VS é adicionar .foldernames aos seus namespaces apenas para tentar ser útil.

este artigo explica muito bem os namespaces:http://www.blackwasp.co.uk/Namespaces.aspx

Ele também tem um exemplo de convenção de nomenclatura no final, embora sua convenção de nome seja sua decisão!;)

Dito isto, a maioria dos lugares em que trabalhei e das pessoas com quem trabalhei começam com o nome da empresa, o que é sensato, pois torna os nomes dos tipos dessa empresa distintos (separados de outros, bibliotecas, fornecedores, projetos de código aberto, etc.)

Answer 7

Você pode adicionar pastas à sua solução para cada namespace.Embora ainda seja compilado em um único executável, ele organiza seus arquivos de origem e fornece (o que eu acho) o efeito desejado?

Normalmente adiciono uma pasta para cada namespace em meu projeto e aninho-os de acordo com a mesma hierarquia (MyApp.View.Dialogs por exemplo)

Answer 8

Namespaces são puramente semânticos.Embora geralmente reflitam uma estrutura de pastas, pelo menos ao usar o Visual Studio IDE, eles não precisam fazer isso.

Você pode ter o mesmo namespace referenciado em várias bibliotecas, feio, mas verdadeiro.

Answer 9

Sempre considerei a organização do arquivo de origem e a atribuição de identificadores a classes e objetos como dois problemas distintos.Costumo manter classes relacionadas em grupos, mas nem todo grupo deve ser um namespace.Existem namespaces (mais ou menos) para resolver o problema de conflitos de nomes - em linguagens de namespace simples como C, você não pode andar dois pés sem tropeçar em identificadores como mycompany_getcurrentdate ou MYCGetCurrentDate, porque o risco de conflito com outra função em uma biblioteca de terceiros (ou sistema) é muito menor.Se você criasse um pacote ou namespace para cada separação lógica, obteria (exemplo Java) nomes de classes como java.lang.primitivewrapper.numeric.Integer, o que é um exagero.