Namespace / estrutura da solução
Peço desculpas por fazer uma pergunta tão generalizada, mas é algo que pode ser um desafio para mim. Minha equipe está prestes a embarcar em um grande projeto que, espera-se, reunirá todas as bases de código aleatórias que evoluíram ao longo dos anos. Dado que este projeto cobrirá a padronização de entidades lógicas em toda a empresa ("Cliente", "Empregado"), pequenas tarefas, grandes tarefas que controlam as pequenas tarefas e serviços de utilidade, estou com dificuldades para descobrir a melhor maneira de estruturar namespaces e estrutura de código.
Embora eu não esteja dando detalhes suficientes para você continuar,você tem algum recurso ou conselho sobre como abordar a divisão de seus domínios logicamente?? Caso isso ajude, a maior parte desta funcionalidade será revelada através de serviços da web, e nós somos umMicrosoft fazer compras com as mais recentes engenhocas e gadgets.
Estou debatendo uma solução massiva com subprojetos para facilitar as referências, mas isso tornará isso muito difícil?Devo concluir a funcionalidade do aplicativo legado ou deixá-lo completamente agnóstico no namespace (fazendo umaOurCRMProduct.Customer
classe versus um genéricoCustomer
classe, por exemplo)?Se cada serviço / projeto tiver seu próprioBAL
eDAL
, ou deveria ser uma assembléia totalmente separada que tudo se refere?Eu não tenho experiência em organizar projetos de longo alcance, apenas one-offs, então estou procurando por qualquer orientação que eu possa obter.