Caso as pastas em uma solução coincidir com o namespace?

votos
98

Caso as pastas em uma solução coincidir com o namespace?

Em um dos meus projetos equipes, temos uma biblioteca de classe que tem muitas sub-pastas no projeto.

Nome do projeto e Namespace: MyCompany.Project.Section.

Dentro deste projeto, existem várias pastas que correspondem a seção de namespace:

  • Pasta Vehiclestem classes no MyCompany.Project.Section.Vehiclesnamespace
  • Pasta Clothingtem classes no MyCompany.Project.Section.Clothingnamespace
  • etc.

Dentro deste mesmo projeto, é outra pasta desonestos

  • Pasta BusinessObjectstem classes no MyCompany.Project.Sectionnamespace

Existem alguns casos como este, onde as pastas são feitas de conveniência organizacional.

A minha pergunta é: Qual é o padrão? Na aula de bibliotecas que as pastas normalmente corresponder à estrutura namespace ou é um saco misturado?

Publicado 07/08/2008 em 13:53
fonte usuário
Em outras línguas...                            


7 respostas

votos
59

Além disso, observe que, se você usar os modelos internos para adicionar classes para uma pasta, que por padrão será colocado em um espaço que reflete a hierarquia de pastas.

As aulas serão mais fáceis de encontrar e que só deve haver razões boas o suficiente.

As regras que se seguem são:

  • Nome do projeto / montagem é o mesmo que o namespace raiz, exceto para o final .dll
  • Única exceção à regra acima é um projeto com um .Core terminando, o .Core é retirado
  • Folders é igual a namespaces
  • Um tipo por arquivo (classe, struct, enum, delegado, etc.) faz com que seja fácil encontrar o arquivo certo
Respondeu 07/08/2008 em 13:58
fonte usuário

votos
25

Eu acho que o padrão, dentro de .NET, é tentar fazê-lo quando possível, mas não para criar estruturas desnecessariamente profundas apenas para aderir a ela como uma regra dura. Nenhum dos meus projetos seguem o namespace == regra estrutura 100% do tempo, às vezes é apenas mais limpo / melhor para sair de tais regras.

Em Java você não tem uma escolha. Eu chamaria isso de um caso clássico do que funciona em teoria vs o que funciona na prática.

Respondeu 07/08/2008 em 13:58
fonte usuário

votos
24

Não.

Eu tentei ambos os métodos em projetos pequenos e grandes, ambos com único (me) e uma equipe de desenvolvedores.

Eu encontrei o caminho mais simples e mais produtiva era ter um único namespace por projeto e todas as classes de entrar nesse espaço de nomes. Está, então, livre para colocar os arquivos de classe em qualquer pastas projeto que você deseja. Não há Messing sobre a adição usando instruções no topo de arquivos de todo o tempo como há apenas um único namespace.

É importante para organizar arquivos de origem em pastas e na minha opinião isso é todas as pastas devem ser usados ​​para. Exigir que essas pastas também mapear para namespaces é desnecessário, cria mais trabalho, e eu encontrei foi realmente prejudicial à organização, porque o fardo incentiva desorganização.

Tome este aviso FxCop por exemplo:

CA1020: Evite namespaces com alguns tipos
causar: Um espaço de nomes diferente do namespace global contém menos de cinco tipos https://msdn.microsoft.com/en-gb/library/ms182130.aspx

Este aviso incentiva o dumping de novos arquivos em uma pasta Project.General genérica, ou mesmo a raiz do projeto até que você tenha quatro classes semelhantes para justificar a criação de uma nova pasta. Será que isso acontecer?

Como encontrar arquivos

A resposta aceita diz que "As classes serão mais fáceis de encontrar e que só deve haver razões suficientemente bom".

Suspeito que a resposta está se referindo a ter múltiplos namespaces em um projeto que não mapear a estrutura da pasta, em vez do que eu estou sugerindo que é um projeto com um único namespace.

Em qualquer caso, enquanto você não pode determinar qual pasta um arquivo de classe está em do namespace, você pode encontrá-lo usando Go To Definition ou caixa explorer a busca solução no Visual Studio. Além disso, este não é realmente um grande problema na minha opinião. Eu não gastar até 0,1% do meu tempo de desenvolvimento sobre o problema de encontrar arquivos para justificar otimizando-o.

conflitos de nome

Claro projeto criando vários namespaces permite ter duas classes com o mesmo nome. Mas isso é realmente uma coisa boa? É talvez mais fácil simplesmente não permitir que de ser possível? Permitindo que duas classes com o mesmo nome cria uma situação mais complexa, onde 90% das coisas que o tempo de trabalho de uma determinada maneira e então de repente você achar que você tem um caso especial. Digamos que você tenha duas classes retângulo definido em namespaces separados:

  • classe Project1.Image.Rectangle
  • classe Project1.Window.Rectangle

É possível bater uma questão que um arquivo de origem deve incluir ambos os namespaces. Agora você tem que escrever o namespace completo em todos os lugares em que file:

var rectangle = new Project1.Window.Rectangle();

Ou confusão sobre com algumas desagradáveis ​​usando declaração:

using Rectangle = Project1.Window.Rectangle;

Com um único namespace em seu projeto você é forçado a vir para cima com diferente, e eu diria mais descritivo, nomes como esta:

  • classe Project1.ImageRectangle
  • classe Project1.WindowRectangle

E uso é o mesmo em todos os lugares, você não tem que lidar com um caso especial quando um arquivo utiliza ambos os tipos.

usando declarações

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs

using Project1;

A facilidade de não ter que adicionar namespaces todo o tempo ao escrever código. Não é o tempo que leva realmente, é a quebra no fluxo de ter que fazê-lo e apenas preenchendo arquivos com lotes de uso de declarações - para quê? Vale a pena?

Alterando a estrutura pasta de projeto

Se as pastas são mapeados para namespaces, em seguida, o caminho da pasta do projeto é efetivamente embutida em cada arquivo de origem. Isto significa que qualquer renomear ou mover de um arquivo ou pasta no projeto requer o conteúdo do arquivo reais para mudar. Tanto a declaração de namespace de arquivos nessa pasta e usando instruções em um monte de outros arquivos que fazem referência aulas nessa pasta. Enquanto as próprias mudanças são triviais com ferramentas, que normalmente resulta em um grande commit que consiste de muitos arquivos cujas aulas ainda nem alterado.

Com um único namespace no projeto você pode mudar a estrutura pasta de projeto como quiser, sem qualquer fonte próprios arquivos sendo modificado.

Visual Studio automaticamente mapeia o espaço de nomes de um novo arquivo para a pasta do projeto é criado em

Lamentável, mas acho que o trabalho de corrigir o namespace é menor que o aborrecimento de lidar com eles. Também tenho o hábito de copiar colar um arquivo existente em vez de usar Adicionar-> Novo.

Intellisense e objeto de navegador

O maior benefício em minha opinião de usar vários namespaces em grandes projetos é ter organização extra quando vendo aulas em qualquer ferramenta que exibe as classes em uma hierarquia de namespaces. Mesmo documentação. Obviamente, ter apenas um namespace nos resultados do projecto em todas as classes que estão sendo exibidos em uma única lista, em vez de divididos em categorias. No entanto, pessoalmente, eu nunca estive perplexo ou atrasado por causa de uma falta de isso para que eu não encontrá-lo um benefício grande o suficiente para justificar vários namespaces.

Embora se eu estivesse escrevendo uma grande biblioteca de classe pública então eu iria provavelmente utilizar vários namespaces no projeto para que a montagem Observava limpo no ferramentas e documentação.

Respondeu 25/03/2015 em 12:22
fonte usuário

votos
21

@lassevk: Eu concordo com estas regras, e têm um mais a acrescentar.

Quando eu tiver aninhado aulas, eu ainda dividi-los para fora, um por arquivo. Como isso:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

e

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
Respondeu 11/09/2008 em 04:45
fonte usuário

votos
4

Eu diria que sim.

Em primeiro lugar, será mais fácil encontrar os arquivos de código reais, seguindo-se os espaços de nomes (por exemplo, quando alguém e-mails que uma exceção de pilha de chamadas nu). Se você deixar suas pastas ir fora de sincronia com namespaces, encontrar arquivos em grandes bases de código torna-se ficando cansativo.

Em segundo lugar, VS irá gerar novas classes criadas em pastas com o mesmo namespace de sua estrutura pasta pai. Se você decidir nadar contra isso, ele será apenas mais um trabalho de encanamento para fazer diariamente quando a adição de novos arquivos.

Claro, isso vai sem dizer que um deve ser conservador sobre como xis pasta hierarquia / namespace profunda vai.

Respondeu 07/08/2008 em 13:57
fonte usuário

votos
3

Sim, eles deveriam, só leva a confusão contrário.

Respondeu 07/08/2008 em 13:55
fonte usuário

votos
0

Qual é o padrão?

Não há um padrão oficial, mas convencionalmente o padrão de mapeamento de pasta-to-namespace é mais utilizado.

Na aula de bibliotecas que as pastas normalmente corresponder à estrutura namespace ou é um saco misturado?

Sim, na maioria das bibliotecas de classe as pastas coincidir com o namespace para facilitar organizacional.

Respondeu 15/07/2018 em 07:00
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more