angularjs - Angular 模块组织/架构

Question

在使用 Angular 一段时间后，我现在看到人们将单个应用程序分解为多个模块，我正在讨论这种方法的优点。

单个模块

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']);

我完全支持模块化，但这些单独的模块是如此具体，以至于它们不会在创建它们的应用程序之外得到任何重用，因此它们不会被重新用于任何其他目的(阅读:不是注入(inject)任何其他模块)。

那么，当外部重用不是一个有效的问题时，人们决定将定义为单个模块的应用程序分成多个模块有什么意义呢？

Answer 1

一般来说

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

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

特别是在 Angular 中

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

同样，UI 元素(指令)可以在整个组织中完全不同的应用程序之间高度共享。因此，出于这个目的，这些东西可以放在它们自己的模块中。