Como você organiza seus projetos? [fechadas]

Você tem algum estilo particular de organização de projetos?

Por exemplo, atualmente estou criando um projeto para algumas escolas aqui na Bolívia, é assim que eu o organizei:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

Como exatamente você organiza seu projeto? Você tem um exemplo de algo que organizou e se orgulha? Você pode compartilhar uma captura de tela do painel Solução?

Na área de interface do usuário do meu aplicativo, estou tendo problemas para decidir sobre um bom esquema para organizar diferentes formulários e onde eles pertencem.

Editar:

Que tal organizar diferentes formas no projeto .UI? Onde / como devo agrupar formas diferentes? Colocar todos eles no nível raiz do projeto é uma má ideia.

Ao projetar um projeto e apresentar a arquitetura, começo de duas direções. Primeiro, analiso o projeto que está sendo projetado e determino quais problemas de negócios precisam ser resolvidos. Eu olho para as pessoas que o usarão e começo com um design bruto de interface do usuário. Neste ponto, estou ignorando os dados e apenas olhando o que os usuários estão pedindo e quem os usará.

Depois de ter um entendimento básico do que eles estão pedindo, eu determino quais são os dados principais que eles estarão manipulando e inicio um layout básico de banco de dados para esses dados. Então começo a fazer perguntas para definir as regras de negócios que cercam os dados.

Partindo de ambas as extremidades de forma independente, sou capaz de elaborar um projeto de maneira a combinar as duas extremidades. Eu sempre tento manter os desenhos separados o máximo de tempo possível antes de combiná-los, mas lembre-se dos requisitos de cada um à medida que avançar.

Depois de entender bem cada extremidade do problema, começo a traçar a estrutura do projeto que será criado para solucionar o problema.

Depois que o layout básico da solução do projeto é criado, analiso a funcionalidade do projeto e configuro um conjunto básico de namespaces usados, dependendo do tipo de trabalho que está sendo realizado. Pode ser coisas como conta, carrinho de compras, pesquisas etc.

Aqui está o layout básico da solução com o qual sempre começo. À medida que os projetos são melhor definidos, eu o refino para atender às necessidades específicas de cada projeto. Algumas áreas podem ser mescladas com outras e posso adicionar algumas, conforme necessário.

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

Eu gosto de dividir meus projetos em camadas

Dessa forma, é mais fácil gerenciar dependências cíclicas. Posso garantir que nenhum projeto esteja importando o projeto View (camada) por engano, por exemplo. Eu também tendem a quebrar minhas camadas em sub-camadas. Portanto, todas as minhas soluções têm uma lista de projetos como este:

• Product.Core
• Product.Model
• Product.Presenter
• Persistência do produto
• Product.UI
• Validação do produto
• Product.Report
• Product.Web

Eles são os maiores "blocos de construção" do meu aplicativo. Em seguida, dentro de cada projeto eu organizo nos espaços para nome mais logicamente, mas isso varia muito. Para a interface do usuário ao criar várias formas, tento pensar em uma divisão espacial e, em seguida, crio namespaces para cada "espaço". Digamos que haja um monte de preferências e controles de usuário, que eu teria um espaço de nome chamado UserPreferences para eles, e assim por diante.

Organização de Projetos

Normalmente, tento dividir meus projetos por namespace, como você diz. Cada camada de um aplicativo ou componente é seu próprio projeto. Quando se trata de como eu decido como dividir minha solução em projetos, concentro-me na reutilização e nas dependências desses projetos. Penso em como outros membros da minha equipe usarão o projeto e se outros projetos que criamos no futuro podem se beneficiar do uso de algum componente do sistema.

Por exemplo, às vezes, basta ter este projeto, que possui um conjunto inteiro de estruturas (email, log etc.):

MyCompany.Frameworks

Outras vezes, convém dividir estruturas em pedaços, para que possam ser importadas individualmente:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Organização de formulários

Organizar formulários em um projeto de interface do usuário realmente se transformará à medida que seu projeto se expandir.

• Pequeno - Uma simples pasta Formulários pode ser suficiente para um projeto muito pequeno. Às vezes, você pode sobrecarregar as estruturas da mesma maneira que os namespaces e tornar as coisas muito mais complicadas do que precisam.

• Médio a Grande - Aqui, geralmente começo a dividir meus formulários em áreas funcionais. Se eu tiver uma parte do meu aplicativo que possui três formulários para gerenciar um usuário e alguns que acompanham os jogos e pontuações de futebol, terei uma área de Formulários> Usuário e uma área de Formulários> Jogos ou algo assim. Realmente depende do resto do projeto, de quantas formas eu tenho e de como eu o particulo.

Lembre-se de que, no final do dia, os espaços para nome e as pastas estão lá apenas para ajudá-lo a organizar e encontrar as coisas mais rapidamente.

Realmente, isso depende da sua equipe, de seus projetos e do que é mais fácil para você. Eu sugeriria que, em geral, você faça projetos separados para cada camada / componente do seu sistema, mas sempre há exceções.

Para obter orientação sobre a arquitetura do sistema, consulte o site de padrões e práticas da Microsoft.

Quando escrevo código no .NET, há uma clara tendência a ter clusters de funcionalidades relacionadas. Cada um dos quais pode ter alguns subconjuntos do mesmo. Eu gosto de dividir os principais grupos fisicamente - um deles por projeto do VS. Em seguida, subdivido ainda mais logicamente usando assemblies Seguindo esse padrão, um dos meus projetos atuais se parece com o seguinte:

• Wadmt (solução)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

Espero que seja útil para você. Os níveis de separação levaram algum tempo para descobrir.

É bom ter um plano para organizar suas soluções e existem várias maneiras de fazê-lo. Temos algumas funcionalidades que são compartilhadas em vários projetos, o que também fornece consistência para nossos usuários. A organização do projeto depende do que estamos fazendo. No seu núcleo, teremos:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

A partir daí, isso realmente depende da configuração. Se tivermos um aplicativo cliente e um front-end da Web (útil para coletar resultados de uso em sala de aula ou outras pesquisas), precisaremos de um projeto que possua o código comumente compartilhado (ou seja, os objetos de dados que serão serializados).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

Outros subprojetos podem ser adicionados conforme necessário. Como eu disse, isso realmente depende do projeto. Alguns projetos são realmente simples e precisam apenas de elementos essenciais. Tentamos combater a separação arbitrária de projetos, de modo que a divisão por camadas realmente faz sentido. As camadas são definidas pelo que precisa ser compartilhado entre projetos, soluções ou pelo que precisa ser plugins / extensões.

É interessante que tantas pessoas não considerem SECO aqui. Aconteceu algumas vezes na minha vida que os desenvolvedores criaram estruturas de diretório que não foram capazes de construir por causa disso. Mantenha o nome do projeto fora dos diretórios de solução e projeto!

Então aqui está o meu caminho:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Quando estou projetando meu aplicativo, sempre o vejo como módulos com algumas dependências entre eles. Quando tenho um design em mente, uso uma estratégia de baixo para cima para desenvolvê-lo. Desenvolvo cada módulo e depois os trabalho juntos.

Bem, esses módulos são projetos sob minha solução (geralmente bibliotecas de classes ). Cada módulo possui um espaço para nome diferente e seu próprio design (contendo classes , etc.).

Um desses módulos é a GUI ( Interface Gráfica do Usuário ).

Também sempre uso uma ferramenta de controle de revisão para rastrear as alterações em cada projeto. Eu sugiro Git . É de código aberto, distribuído e gratuito para uso.

Cada vez que inicio um novo projeto, recebo uma ampla especificação do que ele deve fazer. O fato de ter essa contribuição me ajuda a fornecer um contexto; portanto, vou em frente e penso no melhor (ou mais apropriado) método para atingir as metas do projeto. Nesse ponto, começo a pensar em quais padrões de design podem ajudar a fornecer a solução pretendida. Aqui é onde eu começo a organizar o projeto, levando em consideração os padrões de design que adotarei para o projeto.

Alguns exemplos:

1. Se o projeto apenas se refira à construção de telas de dados de entrada. Provavelmente eu usaria um padrão MVC.
2. Se o projeto for usado como uma interface de usuário pesada que mais suporta múltiplas plataformas, um padrão de desgin da MVVM se tornará útil.

Lembre-se de que tudo isso forçará você a organizar seu projeto de uma maneira específica.

Aqui estão algumas leituras para você:

Padrões de design .Net .

Padrões de design .

Projeto Orientado a Objetos .

Espero que isto ajude.