Application Structure

ou Estrutura da aplicação

Overall Guidelines

ou Orientações gerais

• Tenha uma visão de curto prazo da implementação e uma visão de longo prazo. Em outras palavras, comece pequeno, mas tenha em mente o caminho que o aplicativo pode tomar. Todo o código do aplicativo vai em uma pasta raiz chamada app. Todo o conteúdo é feito com um recurso por arquivo. Cada controlador (controller), serviço (service), módulo (module), visão (view) está em seu próprio arquivo. Todos os scripts de terceiros são armazenados em uma outra pasta raiz e não na pasta app. Não fui eu quem escreveu esses scripts, então eu não quero que eles baguncem meu aplicativo (bower_components,scripts, lib).

  Nota: Encontre mais detalhes sobre essa estrutura em esse post original sobre a estrutura da aplicação.

Layout

• Coloque os componentes que definem o layout geral do aplicativo em uma pasta chamada layout. Eles podem incluir uma view e um controller que agem como recipiente para o app, navegação, menus, áreas de conteúdo, e outras regiões.

  Por que? Organiza todos os layouts em um único lugar reutilizado em toda a aplicação.

Folders-by-Feature Structure

ou Estrutura de Pastas-por-Recurso

• Crie pastas nomeadas para cada recurso que elas representam. Quando uma pasta cresce ao ponto de conter mais de 7 arquivos, comece considerar a criação de uma pasta para eles. O seu limite pode ser diferente, por isso, ajuste conforme necessário.

  Por que? O desenvolvedor pode localizar o código, identificar o que cada arquivo representa em resumo, a estrutura é plana como deve ser, e não há nenhum nome repetido ou redundante.

  Por que? As orientações LIFT estão todas sendo respeitadas.

  Por que? Através da organização do conteúdo, ajuda a reduzir o app de tornar-se desordenado e mantêm alinhado com as diretrizes LIFT.

  Por que? Quando há um grande número de arquivos (10+) localizá-los é mais fácil com estruturas de pastas consistentes e mais difícil em estruturas planas.

  /**
   * recomendado
   */
  
  app/
      app.module.js
      app.config.js
      app.routes.js
      components/
          calendar.directive.js
          calendar.directive.html
          user-profile.directive.js
          user-profile.directive.html
      layout/
          shell.html
          shell.controller.js
          topnav.html
          topnav.controller.js
      people/
          attendees.html
          attendees.controller.js
          speakers.html
          speakers.controller.js
          speaker-detail.html
          speaker-detail.controller.js
      services/
          data.service.js
          localstorage.service.js
          logger.service.js
          spinner.service.js
      sessions/
          sessions.html
          sessions.controller.js
          session-detail.html
          session-detail.controller.js
  

  

  Nota: Não estruture seu aplicativo usando pastas-por-tipo. Isto requer alternar entre várias pastas ao trabalhar em um recurso e fica difícil de manejar quando o aplicativo cresce rapidamente para 5, 10 ou 25+ views e controllers (e outros recursos), o que torna mais difícil do que pasta-por-recurso para localizar arquivos.

  /*
  * evite
  * Alternativa pastas-por-tipo.
  * Eu recomendo "pastas-por-recurso".
  */
  
  app/
      app.module.js
      app.config.js
      app.routes.js
      controllers/
          attendees.js
          session-detail.js
          sessions.js
          shell.js
          speakers.js
          speaker-detail.js
          topnav.js
      directives/
          calendar.directive.js
          calendar.directive.html
          user-profile.directive.js
          user-profile.directive.html
      services/
          dataservice.js
          localstorage.js
          logger.js
          spinner.js
      views/
          attendees.html
          session-detail.html
          sessions.html
          shell.html
          speakers.html
          speaker-detail.html
          topnav.html
  

De volta ao topo