Como devo estruturar módulos em um aplicativo Angular.js?

5

Eu sou relativamente novo no Angular.js, e um que me confunde é como usar melhor os módulos em um aplicativo. Parece-me que os módulos podem conter qualquer uma das outras construções comuns no AngularJS (controladores, diretivas, filtros, serviços, etc.), mas a partir daqui não tenho certeza qual módulo (s) deve conter quais coisas.

  • Devo ter um módulo que contenha todos os outros objetos em meu aplicativo? Isto parece ser o mais fácil de configurar, mas este cheira a God Object Anti-Pattern para mim.

  • Devo dividir os módulos por tipos de objetos? ou seja, um módulo para controladores, um para diretivas, etc.?

  • Devo dividi-los por uso? Para que todas as diretivas, serviços e filtros usados em parte do aplicativo estejam juntos?

  • alguma outra estratégia que ainda não vi / pensei?

Qualquer ajuda seria muito apreciada.

    
por GSto 13.05.2013 / 17:28
fonte

1 resposta

1

Provavelmente você não é novo e já tem a resposta. Os links de @KeesDijk e @Aaron já devem fornecer uma resposta abrangente.

Como eu também já fiz a mesma pergunta antes, essa resposta pode ser útil para quem começa a aprender Angularjs.

Should I have one module that contains all of the other objects in my application? This seems the easiest to set up, but this smells of the God Object Anti-Pattern to me.

Você tem a resposta. A menos que seja um aplicativo realmente pequeno, ter um único módulo geralmente não é uma boa escolha.

Should I divide modules up by types of objects? i.e. one module for controllers, one for directives, etc.?

Digamos que você tenha 4 módulos para controladores / diretivas / serviço / filtro, uma vez que você tenha mais de 30 componentes. Cada módulo tem 7-8 componentes. Como você tem um aplicativo maior, você terminará como a opção anterior.

Além disso, se você quiser reutilizar uma funcionalidade, como o gerenciamento de usuários, precisará depender de vários módulos.

Should I divide them by use? So that all directives, services, and filters that are used for part of the application are together?

Estas são as práticas recomendadas mais comuns. Um módulo / pasta por uma funcionalidade. É mais fácil de reutilizar, ler (por outros programadores) e escalar à medida que o aplicativo cresce.

Reutilização também é melhor, você pode apenas ter uma dependência no módulo 'usuário'.

some other strategy I haven't yet seen / thought of?

Com base na opção anterior, você pode ter variantes.

  • Pode ser útil estruturar seu módulo de maneira aninhada por sub-funcionalidade. Por exemplo, você pode ter o módulo 'user' que contém os módulos 'user-list' e 'user-edit'. (Veja link por exemplo)
  • Você pode ter um módulo comum / compartilhado separado do restante e prefixá-los. Ex. 'comum', 'usuário de modelo comum', 'common-ui-modal', etc.
por 27.03.2015 / 21:06
fonte