Diretrizes de nome de espaço e classe

15

Estou tendo problemas para nomear minhas classes e serviços corretamente quando utils e outras classes de ajuda estão envolvidas.

Como você estruturaria o seguinte:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

etc ...

Eu tenho vários serviços com as mesmas necessidades que o serviço acima. Um pensamento é separar tudo isso em um namespace adequado, fazendo com que pareça algo assim:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

e assim por diante. Todo namespace é obviamente uma pasta separada. Mas isso não parece 100%, já que provavelmente há mais DateValidators nos outros serviços, o que pode facilmente levar a uma referência indesejada.

E também o Services.EventService.EventService.cs inclui o nome da classe no namespace, o que também não é bom. Você poderia usar Services.Event.EventService.cs , mas é claro que já existe uma entidade com esse nome.

Este é o modelo de domínio.

    
por Mattias 07.09.2011 / 17:55
fonte

3 respostas

5

Acho que a única grande coisa que você poderia fazer para melhorar seu namespace aqui é remover Service do seu namespace EventService . Eu também ajustaria os namespaces para ficarem mais assim:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Eu ainda acho que poderia usar algumas melhorias.

Eu costumava gostar de namespaces, mas hoje em dia eu acho que menos é mais. O aninhamento profundo de seus namespaces pode tornar seu código muito detalhado e reduzir muito a sua capacidade de herança. Em seu código, por exemplo, uma classe DateValidator poderia ser facilmente usada em outro lugar, portanto, não deveria ter muitos namespaces acima dela, já que outros serviços além do EventService agora podem aproveitar uma classe DateValidator. O mesmo se aplica aos métodos de extensão. Não há tempo (que eu possa ver) onde você precisa ver todos os seus métodos de extensão ao mesmo tempo, portanto, faz mais sentido agrupá-lo com o que está relacionado. Nesse caso, EventExtensions provavelmente está vinculado ao seu EventService , então, logicamente, eles devem ficar juntos na minha opinião.

    
por 07.09.2011 / 22:43
fonte
5

Por que você não lê as Diretrizes gerais de nomenclatura e Diretrizes de nomeação de namespace da Microsoft para seguir um padrão universal?

Acho que a fórmula <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>] simplesmente funciona bem.

    
por 09.09.2011 / 06:51
fonte
2

O design de namespace adequado considerará o design físico e lógico.

Embora a justificativa original para namespaces fosse principalmente para evitar confrontos de nomes entre nomes de objetos e métodos, ela se tornou um elemento importante na arquitetura e no design geral da solução. Você não apenas deseja que sua hierarquia conceitual e design lógico façam sentido, mas provavelmente também deseja que seu código seja organizado em bibliotecas bem projetadas e facilmente reutilizáveis que possam ser facilmente agrupadas em outros projetos e produtos posteriormente. Esse talvez seja mais o resultado desejado do bom design físico.

Veja o .NET Framework e como as unidades de funcionalidade relacionadas são fornecidas a você em montagens de tamanho razoável. Você pode inserir uma referência e uma instrução de uso e, de repente, você tem uma funcionalidade relevante disponível sem ter que arrastar qualquer número de pias de cozinha. Isso ocorre porque o design físico do .NET Framework, incluindo o namespace inteligente, contém códigos logicamente relacionados em unidades implantáveis relacionadas fisicamente. Ao criar um excelente mapeamento entre namespaces e assemblies, os arquitetos e desenvolvedores do framework .NET da Microsoft facilitaram significativamente seu trabalho (é claro que alguns podem argumentar de outra forma, mas estou bastante feliz com o que eles fizeram).

A namespace em C # é bastante arbitrária, na verdade. Você pode colocar namespaces nos lugares mais estranhos, em assemblies muito distantes um do outro. Qualquer disciplina útil nessa área é realmente sua contribuição pessoal para um produto de software bem organizado. Eu não me atreveria a te aconselhar exatamente o que fazer em cada caso. O que espero conseguir, nesta resposta, é fazer com que você pense em design físico e em design lógico ao definir seus namespaces. Quanto mais você mantiver as coisas logicamente relacionadas e implementáveis (fisicamente), mais fáceis serão as coisas mais tarde, tanto para você quanto para outras pessoas que talvez precisem lidar com seu código algum dia.

Então, por favor, pense em como seu código será empacotado em assemblies e componentes quando você resolver seus problemas de namespaces!

    
por 09.09.2011 / 00:58
fonte