Qual é a melhor forma de estruturar um projeto? [fechadas]

Question

Eu estava pensando sobre como eu deveria estruturado meus projetos.

Temos alguns projetos que são (re) utilização em outros projetos.

Quer dizer, o nosso projeto de dados e projeto de modelo são o uso em um-para-muitos outros projetos.

O que eu realmente o que sei é como estruturar este tipo de projeto, qual a melhor maneira de nomeá-lo?

Em um aplicativo de camada 3 standard, é gostaria algo como:

1. DAL, DataAccessLayer, dados ...
2. Modelo, BusinessObject, BOL ...
3. UI, Vista, ...

Quaisquer outras ideias?

Em cada trabalho da empresa I, eles tem modo diferente para organizá-lo, há um melhor que o outro? Qual deles você usa e qual deles você prefere e por quê?

Thx!

Answer 1

Para a camada de dados, eu costumo usar:

Company.ProjectName.Data (isto é AdventureWorks.OrderManager.Data)

Para camada de negócios prefiro algo como "ObjectModel" (eu usei "Business" ou "BusinessLogic" mas esta é a área onde vem dados juntos em objetos / classes então por que não nomeá-lo assim?).

Company.ProjectName.ObjectModel (isto é AdventureWorks.OrderManager.ObjectModel)

Para UI, eu como qualquer bom e velho "UI" ou "Apresentação" ...

Company.ProjectName.Presentation (isto é AdventureWorks.OrderManager.Presentation)

Answer 2

Isso é muito bonito o que eu faço, exceto ive tenho um par de projetos de biblioteca, onde eu tento colocar todo o meu código reutilizável. Então meu modelo e DAL sentar em cima desses librarys, apenas adicionando detalhes do projeto para eles

Answer 3

Na maior parte eu usar arquitetura em camadas, como recomendado no Microsoft Patterns & Practices Application Architecture para NET: Aplicações e Serviços Projetando . Documento descreve a arquitetura e tecnologias .NET para implementá-lo.

Answer 4

A arquitetura de software depende do tipo de software para construir. Se você quer fazer do kernel programação outros princípios se aplicam comparado a fazer desenvolvimento de aplicações. No entanto, outros princípios se aplicam quando você está indo para fazer a simulação física, software tempo-forecast, do IDE software ou compiladores.

Eu suponho que você quer fazer developement aplicação. Bem, então você provavelmente vai querer projetar seu software em todo o domínio que você está indo para refletir. Mas mesmo assim, há muitas opções.

Para mais detalhes neste tópico grande, eu sugiro fortemente para ler Domain Driven Design de Eric Evans e Applying Domain-Driven Design and Patterns de Jimmmy Nilsson.

Answer 5

Atualmente estou trabalhando em aplicativo Web front-end que tem uma arquitetura de 3 camadas:

• nível de cliente (navegador)
• Camada de aplicativo (servidor de aplicativos Java EE, em que o aplicativo vai viver)
• Backend camadas (de mainframe e legados apps, vários bancos de dados)

Ele tem uma arquitetura em camadas, e as camadas na camada de aplicação são:

• Camada de apresentação: gera a interface do usuário que será usado na camada de cliente
• camada de aplicação: o equivalente de casos de uso, contém lógica de aplicação
• camada Serviço: mapeia lógica de domínio e os dados de back-end nível em um modelo Java
• Integração da camada: comunica com a camada de back-end e contém gateways para JMS, e-mail ... e DAOs e outras coisas

Este é apenas um exemplo de estrutura do projeto, eo resultado final vai depender do tipo de aplicação. Você pode ler mais em minha resposta para esta questão na divisão e estratégia de nomeação para pacotes.

Você pode adicionar / camadas de swap / remover como você vê o ajuste. Em uma SOA, por exemplo, você pode camada uma camada Webservice em cima da camada de aplicação ou camada de serviço, de modo que o ESB (Enterprise Service Bus) pode se conectar a sua aplicação ou serviços. Se nada disso é impossível ou parece muito difícil, você não tem uma arquitetura e design ideal.

Ao pensar sobre a estrutura do seu projeto e para permitir cenários como o descrito acima, algumas propriedades importantes de seus módulos e componentes que deseja são:

• Testability
• Reutilização
• Maintainability

Você pode conseguir isto, projetando para baixo acoplamento e alta coesão. Escolhendo uma arquitetura em camadas, agrupando módulos pelo nível de funcionalidade / abstração é um bom começo. Dentro de cada agrupamento camada adicional por funcionalidade ajuda também. Deixar cada camada mais específico depende apenas as interfaces de uma camada mais geral reduz o acoplamento também.