单一模块

angular.module('myApp', []);
angular.module('myApp').controller('FooCtrl', function(){});
angular.module('myApp').service('foo', function(){});
angular.module('myApp').directive('fooElement', function(){});

多个模块

angular.module('myApp.Controllers', []);
angular.module('myApp.Controllers').controller('FooCtrl', function(){});
angular.module('myApp.Services', []);
angular.module('myApp.Services').service('foo', function(){});
angular.module('myApp.Directives');
angular.module('myApp.Directives').directive('fooElement', function(){});

// Then inject the separate modules into the "parent" module
angular.module('myApp', [
    'myApp.Controllers',
    'myApp.Services',
    'myApp.Directives']);

我完全是模块化的，但是这些单独的模块是如此具体，以至于它们不会在创建它们的应用程序之外得到任何重用，以至于它们不会被重新用于任何其他目的（读取：not not注入任何其他模块）。

那么当外部重用不是一个有效的问题时，人们会决定将你的app定义为单个模块分成多个模块的重点是什么？

Answer 1

一般来说

对于具有模块化应用程序开发的任何平台，都可以提出同样的问题。如果所有代码仅在一个地方使用，为什么要将.NET应用程序分离到单独的程序集中？

它允许对功能块进行版本控制。
它允许在其他应用程序之间重用/共享功能块。
它在功能块之间提供了更清晰的分离。

在Angular中，特别是

在Angular中，也有一些优点，即并非所有应用程序的功能都需要在同一个单页应用程序中。例如，并非应用程序的每个用户在加载主应用程序时都需要加载用户管理代码。因此，您可以将其分成不同的SPA。但是新的SPA可能需要共享API访问代码或UI元素，因此这些内容可以封装在模块中。

同样，UI元素（指令）是整个组织中完全不同的应用程序之间可以高度共享的东西。所以那些东西可以在他们自己的模块中，仅仅是为了这个目的。

Answer 2

在许多情况下，将典型角度模块组织和/或分解为单独的模块非常有意义;它使应用程序更易于维护，并使应用程序代码更易于访问，更容易分发。

例如，如果你看一下here所采用的方法，你可以更好地了解角度应用程序如何更原型地编写和组织，控制器来自basecontroller等等。

至于为什么你要将每个角度提供者类型分解为自己的模块，我不能说。它似乎不赞成许多优秀设计原则，也不是每个提供商类型的组织模块为应用程序或开发人员提供了很多好处。它似乎是每个人在一些答案中看到的那些愚蠢的事情之一，然后赶上并开始在所有地方的博客文章中出现（与useXDomain上的虚构$http标志不同）。

提倡它，我能想到的最好的论据是 - 它可以为你提供一种每个提供者类型的测试正交性。

Answer 3

我目前正在使用按功能划分为模块的模块方法，但我开始相信它没有太大的实际好处。但请继续阅读。首先，让我们回顾一下那里......

MiškoHevery在此讨论：

https://www.youtube.com/watch?v=ZhfUv0spHCY&t=34m19s

然后是Naomi Black的帖子：

http://blog.angularjs.org/2014/02/an-angularjs-style-guide-and-best.html

参考这些文件：

https://google-styleguide.googlecode.com/svn/trunk/angularjs-google-style.html https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub

最新版本的角度文档也说明了：

...我们建议您将应用程序分解为多个模块   像这样：


每个功能的模块

每个可重用组件的模块（尤其是指令和过滤器）

应用程序级模块，它依赖于上述模块并包含任何初始化代码。

因此，尽管最新的文档为每个功能推荐了一个模块，但目前还不清楚它的好处是什么，特别是考虑到Miško的话题。上面引用的文档仅说明可以在适当的地方使用模块。不是，不应该。排序可以。如果你想。当然，除非您正在开发一个独立的可重用组件，否则它是完全合理的。

可以注意到，使用模块允许明确说明应用程序块之间的依赖关系，但也不清楚这是如何特别补充或改进已经使用常规DI所做的事情。

此外，我们必须明确区分代码组织和角度模块。这些并不是真正直接相关的。您可以将代码整齐地组织到子目录中，并在适当的地方使用单个角度模块或几个模块。这与Java不同，它需要保持目录结构与包同步。然后它可能是将苹果与橙子进行比较。现在，角度模块是否有助于更好的代码组织是另一个主题，更多的品味问题可能呢？（我个人喜欢每个功能模块的概念，并且更明确）。

坚持，因为还存在未来角度功能的问题，如延迟加载。根据Miško的说法，每个特征模块的方法应该可以很好地使用它，现在在文档中建议使用，所以最保守的方法可能就是坚持使用。

<强>摘要

目前，这些优势尚不清楚，但建议并且可能与未来的功能兼容，因此最好遵循当前每个功能模块的建议。

不按类型分割，如问题代码示例所示。这是明确的。

Answer 4

为组织而组织？谁知道！当用于将所有内容连接在一起的方法（grunt，ASP.NET bundle等）在排序方面做得不好时，有时会发生这种情况，所以一切都变成了模块，因为模块声明（带有依赖项）在添加到模块的任何内容之前，必须由浏览器加载。

在应用程序的控制器，服务和指令之间，这种划分对我来说特别愚蠢，因为无论如何所有这些事情都会相互强烈耦合。我认为Angular Seed项目似乎促进了这一点，我感到很遗憾。

对于另一种选择，请查看ng-boilerplate project背后的组织结构，它将事物组织到功能目录中，以便您的目录结构基于您的路由以及控制器，模板和测试任何特定功能都被组合在一起。

Answer 5

每个开发人员都可以建议他为AngularJs模块构建一个好的架构。但有时候架构存在一些问题/冲突，你不知道如何解决。例如你创建了“moduleA”和“moduleB”在“moduleA”中你需要一些已经在“moduleB”中定义的函数。与“moduleB”相同的方式取决于“moduleA”。但这里是一个循环的DI。为了解决这样的问题，你必须创建你的模块不是“实体”的逻辑。你必须创建具有“功能”逻辑的模块。如果你需要更多信息，这里有一个很酷且正确的代码片段。

http://www.w3docs.com/snippets/angularjs/angularjs-modules-good-architecture.html

Answer 6

到目前为止，Angular Modules一无所获。除了将第三方角度代码加载到您的应用程序中并在测试期间进行模拟。除此之外，没有理由在您的应用中使用多个模块。 - 对于Angular 1.2至少也是如此。

在1.3 beta中，文档说......

每个功能的模块
每个可重用组件的模块（尤其是指令和组件）过滤器）
依赖于上述模块的应用程序级模块并包含任何初始化代码。

以上是一个建议。根据您的需求量身定制。

角度模块组织/架构

单一模块

多个模块

6 个答案:

一般来说

在Angular中，特别是