Estrutura de namespace/solução

Question

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, esperançosamente, reunirá todas as bases de código aleatórias e únicas que evoluíram ao longo dos anos.Dado que este projeto abrangerá a padronização de entidades lógicas em toda a empresa ("Cliente", "Funcionário"), pequenas tarefas, grandes tarefas que controlam as pequenas tarefas e serviços utilitários, estou lutando para descobrir a melhor maneira de estruturar o namespaces e estrutura de código.

Embora eu ache que não estou lhe dando detalhes suficientes para continuar, você tem algum recurso ou conselho sobre como abordar a divisão lógica de seus domínios?Caso ajude, a maior parte desta funcionalidade será revelada através de serviços web, e somos um Microsoft compre com todos os aparelhos e gadgets mais recentes.

• Estou debatendo uma solução massiva com subprojetos para facilitar as referências, mas isso tornará tudo muito complicado?
• Devo encerrar a funcionalidade do aplicativo legado ou deixá-la completamente agnóstica no namespace (fazendo uma OurCRMProduct.Customer classe versus um genérico Customer classe, por exemplo)?
• Cada serviço/projeto deve ter seu próprio BAL e DAL, ou deveria ser um assembly totalmente separado ao qual tudo faz referência?

Não tenho experiência na organização de projetos tão abrangentes, apenas pontuais, por isso estou procurando orientação possível.

Answer 1

Há um milhão de maneiras de esfolar um gato. No entanto, o mais simples é sempre a melhor. Que maneira é a mais simples para você? Depende de suas necessidades. Mas existem algumas regras gerais do polegar eu seguir.

Em primeiro lugar, reduzir o número total de projetos, tanto quanto possível. Quando você compila vinte vezes por dia, que minuto extra acrescenta-se.

Se seu aplicativo é projetado para extensibilidade, considere dividir suas montagens ao longo das linhas do desenho de implementação vs.. Coloque suas interfaces e classes base em uma assembléia pública. Criar uma montagem para implementações dessas classes da sua empresa.

Para grandes aplicações, mantenha a sua lógica de interface do usuário e lógica de negócio separado.

simplificar a sua solução. Se parece muito complexo, é provavelmente. Combine, reduzir.

Answer 2

Meu conselho, tendo embarcado em um compromisso semelhante, é não agonizar sobre os espaços de nomes ..

Apenas começar a desenvolver com algumas orientações soltas importantes, porque no entanto você começa, seu projeto é orgânico, e você irá acabam reorganizando os espaços de nomes e classes ao longo do tempo.

Não perca tempo falando demais sobre o seu projeto. Basta fazê-lo.

Answer 3

Eu recentemente experimentou exatamente o mesmo no trabalho. Lotes de código ad-hoc que precisava ser estruturado e organizado.

A sua verdadeira difícil no início, uma vez que não é tanto. Eu acho que o melhor conselho que eu poderia dar é apenas para investir tempo em que no vento para baixo em uma tarde de sexta-feira, por um par de semanas eu iria escolher apenas um app / pedaço de código, examinar o que era lá, pensar sobre o que poderíamos fazer genérico, copiá-lo, colocá-lo na nova biblioteca onde quer que eu pensei que deveria ser. Uma vez que eu tinha todo o código dentro de um aplicativo migrado, Eu, então, trabalhar em refatoração a aplicação ao trabalho do quadro comum .. Isto às vezes causado problemas que precisavam ser fixo, mas desde que a sua completa não deve ser muito grande um acordo.

Peça por peça, isso é a única maneira de fazê-lo.

Em termos de estrutura, tentei tipo de imitar o MS namespacing uma vez que para a maioria de parte o seu muito lógico (por exemplo, Company.Data , Company.Web , < em> Company.Web.UI e assim por diante.

Um dos principais benefícios é provavelmente a quantidade de dupe código removido. Sim um pouco refactoring foi necessário nos aplicativos, mas a base de código é um magro muito, e de muitas maneiras "mais inteligentes".

Outra coisa que notei é que eu muitas vezes têm problemas tentando descobrir o , onde para colocar coisas (em termos de namespacing) desde que eu não tinha certeza de que ele pertencia. Agora este realmente me em causa, eu considerava-a como um mau cheiro tal. Desde o re-org tudo agora cai no espaço muito mais agradável. E com o (agora quantidade muito pequena) de código specfic aplicação, eles são colocados em Company.Applications.ApplicationName Isto ajuda-me realmente pensar sobre objetos de negócios muito mais desde que eu não quero muito dentro deste namespace , então eu vir acima com projetos mais flexíveis.

Desculpe pelo longo post .. É uma espécie de caminhadas!

Answer 4

Nós nomear as montagens em .NET da seguinte maneira Company.Project.XXXX.YYYY onde XXXX é o Projeto e YYYYY é subprojeto, por exemplo:

• LCP.AdmCom.Common
• LCP.AdmCom.BusinessObjects
• LCP.AdmCom.Common.Dal

Nós levamos isso a partir de uma chamada livro Framework Design Guidelines por Krzysztof Cwalina (Autor), Brad Abrams (Autor)

Answer 5

Para grandes projectos a abordagem que eu gostaria de ter é ter um espaço de nomes de domínio para os meus objetos de negócios e, em seguida, usar os dados de transferência Objects (DTO) em minhas camadas onde for necessário armazenamento e recuperação do objeto de negócios. Um DTO é um objeto simples que não contém qualquer lógica de negócios.

Aqui está um link que explica um DTO:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

Answer 6

soluções grandes com lotes de projetos pode ser muito lento para compilar, mas são mais fáceis de gerir em conjunto.

Muitas vezes eu tenho montagens teste de unidade na mesma solução como os que estamos testando, como você tendem a alterá-los juntos.