多亏了大量有价值的资源，我得到了一些在 AngularJS 应用程序中实现组件的一般性建议:

控制员

• 控制器应该只是模型和视图之间的一个 夹层。尽量使它成为 瘦。

• 在控制器中强烈推荐使用 避免商业逻辑，它应该被移动到模型中。

• 控制器可以使用方法调用与其他控制器通信(当子控制器需要与父控制器通信时可以使用)或者使用 $发射、 $广播和 $方法。应尽量减少发出和广播的讯息。

• 控制器应该 不在乎表现或 DOM 操作。

• 尝试使用 避免嵌套控制器。在这种情况下，父控制器被解释为 model。注入模型作为共享服务。

• 控制器中的作用域 应用于具有视图和
  封装 视图模型作为 演示模型设计模式。

范围

作为 模板中的只读和 在控制器中只写处理范围。作用域的目的是引用模型，而不是作为模型。

在执行双向绑定(ng-model)时，请确保不直接绑定到范围属性。

模特

AngularJS 中的模型是由 服务定义的 单身。

模型提供了一种分离数据和显示的优秀方法。

模型是单元测试的主要候选者，因为它们通常只有一个依赖项(某种形式的事件发射器，通常是 $rootScope) ，并且包含高度可测试的 领域逻辑领域逻辑。

• 模型应视为特定单元的实现。 它是以单一责任原则为基础的。单元是一个实例，它负责自己的相关逻辑的范围，这些逻辑可能代表现实世界中的单个实体，并在编程世界中用 数据和状态来描述它。

• 模型应该封装应用程序的数据并提供一个 < strong > API 访问和操作这些数据

• 型号应该是 便携式的，这样它可以很容易地运输到类似的 申请书

• 通过隔离模型中的单元逻辑，您可以更容易地 定位、更新和维护

• 模型可以使用通用的更一般的全局模型的方法 整个应用程序

• 尽量避免使用依赖注入将其他模型组合到你的模型中，如果它不是真正依赖于减少组件耦合和增加单元 可测试性和 可用性。

• 尽量避免在模型中使用事件侦听器。这使得它们更难测试，并且通常根据单一责任原则扼杀模型。

模型实现

由于模型应该根据数据和状态封装某些逻辑，因此它应该在体系结构上限制对其成员的访问，从而保证松耦合。

在 AngularJS 应用程序中实现这一点的方法是使用 工厂服务类型定义它。这将允许我们非常容易地定义私有属性和方法，并且在单个位置返回公共可访问的属性和方法，这将使它对开发人员来说真正可读。

一个例子 :

angular.module('search')
.factory( 'searchModel', ['searchResource', function (searchResource) {


var itemsPerPage = 10,
currentPage = 1,
totalPages = 0,
allLoaded = false,
searchQuery;


function init(params) {
itemsPerPage = params.itemsPerPage || itemsPerPage;
searchQuery = params.substring || searchQuery;
}


function findItems(page, queryParams) {
searchQuery = queryParams.substring || searchQuery;


return searchResource.fetch(searchQuery, page, itemsPerPage).then( function (results) {
totalPages = results.totalPages;
currentPage = results.currentPage;
allLoaded = totalPages <= currentPage;


return results.list
});
}


function findNext() {
return findItems(currentPage + 1);
}


function isAllLoaded() {
return allLoaded;
}


// return public model API
return {
/**
* @param {Object} params
*/
init: init,


/**
* @param {Number} page
* @param {Object} queryParams
* @return {Object} promise
*/
find: findItems,


/**
* @return {Boolean}
*/
allLoaded: isAllLoaded,


/**
* @return {Object} promise
*/
findNext: findNext
};
});

创建新实例

尽量避免让工厂返回一个新的能力函数，因为这将开始打破依赖注入，而库将表现得很尴尬，尤其是对于第三方。

完成同样事情的一个更好的方法是使用工厂作为 API 来返回一个对象集合，其中附加了 getter 和 setter 方法。

angular.module('car')
.factory( 'carModel', ['carResource', function (carResource) {


function Car(data) {
angular.extend(this, data);
}


Car.prototype = {
save: function () {
// TODO: strip irrelevant fields
var carData = //...
return carResource.save(carData);
}
};


function getCarById ( id ) {
return carResource.getById(id).then(function (data) {
return new Car(data);
});
}


// the public API
return {
// ...
findById: getCarById
// ...
};
});

全球模式

一般来说，尽量避免这种情况，并正确设计您的模型，因此它可以被注入到控制器，并在您的视图中使用。

特别是在某些情况下，一些方法需要在应用程序中进行全局可访问性。 为了使它成为可能，您可以在 $rootScope中定义“ 很普通”属性，并在应用程序引导期间将其绑定到 CommonModel:

angular.module('app', ['app.common'])
.config(...)
.run(['$rootScope', 'commonModel', function ($rootScope, commonModel) {
$rootScope.common = 'commonModel';
}]);

所有的全局方法都将存在于“ 很普通”属性中。这是某种 命名空间。

但是不要在 $rootScope中直接定义任何方法。这可能导致在视图范围内与 ngModel 指令一起使用时出现 意想不到的行为，通常会造成范围方法覆盖问题。

资源

资源允许您与不同的 资料来源交互。

应使用 单一责任原则单一责任原则实现。

在特殊情况下，它是 HTTP/JSON 端点的 可重复使用代理。

资源被注入到模型中，并提供了发送/检索数据的可能性。

资源实现

一个工厂，它创建一个资源对象，允许您与 RESTful 服务器端数据源交互。

返回的资源对象具有操作方法，这些方法提供高级行为，而不需要与低级 $http 服务交互。

服务

模型和资源都是服务 。

服务是独立的，松散耦合功能单元是自包含的。

服务是 Angular 从服务器端为客户端 Web 应用带来的一个特性，服务在服务器端已经普遍使用了很长时间。

角度应用中的服务是用依赖注入连接在一起的可替代对象。

角度有不同类型的服务。每一个都有自己的用例。详情请阅读 了解服务类型。

尝试在应用程序中考虑 服务体系结构的主要原则。

一般来说，根据 网上服务词汇:

服务是一种抽象资源，表示 执行任务，形成一个连贯的功能，从点 查看提供者实体和请求者实体 服务必须由具体的供应商代理实现。

客户端结构

一般来说，应用程序的客户端被划分为 模组。每个模块应该是 可测试的作为一个单元。

尝试根据 特性/功能或 风景定义模块，而不是按类型定义。 详情请参阅 米斯科的报告。

模块组件通常可以按类型进行分组，如控制器、模型、视图、过滤器、指令等。

但模块本身仍然是 可重复使用，可转让和 可测试的。

对于开发人员来说，找到代码的某些部分及其所有依赖项也要容易得多。

详情请参阅 大型 AngularJS 和 JavaScript 应用中的代码组织。

文件夹结构的一个例子 :

|-- src/
|   |-- app/
|   |   |-- app.js
|   |   |-- home/
|   |   |   |-- home.js
|   |   |   |-- homeCtrl.js
|   |   |   |-- home.spec.js
|   |   |   |-- home.tpl.html
|   |   |   |-- home.less
|   |   |-- user/
|   |   |   |-- user.js
|   |   |   |-- userCtrl.js
|   |   |   |-- userModel.js
|   |   |   |-- userResource.js
|   |   |   |-- user.spec.js
|   |   |   |-- user.tpl.html
|   |   |   |-- user.less
|   |   |   |-- create/
|   |   |   |   |-- create.js
|   |   |   |   |-- createCtrl.js
|   |   |   |   |-- create.tpl.html
|   |-- common/
|   |   |-- authentication/
|   |   |   |-- authentication.js
|   |   |   |-- authenticationModel.js
|   |   |   |-- authenticationService.js
|   |-- assets/
|   |   |-- images/
|   |   |   |-- logo.png
|   |   |   |-- user/
|   |   |   |   |-- user-icon.png
|   |   |   |   |-- user-default-avatar.png
|   |-- index.html

角度应用程序-https://github.com/angular-app/angular-app/tree/master/client/src实现了角度应用结构的一个很好的例子

现代应用程序生成器 https://github.com/yeoman/generator-angular/issues/109也考虑到了这一点

与 Artem 的建议相比，这是一个小问题，但在代码可读性方面，我发现最好完全在 return对象内部定义 API，以尽量减少在代码中来回查看定义了哪些变量:

angular.module('myModule', [])
// or .constant instead of .value
.value('myConfig', {
var1: value1,
var2: value2
...
})
.factory('myFactory', function(myConfig) {
...preliminary work with myConfig...
return {
// comments
myAPIproperty1: ...,
...
myAPImethod1: function(arg1, ...) {
...
}
}
});

如果 return对象看起来“太拥挤”，这是一个迹象，表明服务做得太多。

我相信伊戈尔对这个问题的看法，正如你提供的引文所示，只是一个更大问题的冰山一角。

MVC 及其衍生物(MVP、 PM、 MVVM)在单个代理中都很好用，但是服务器-客户端架构在任何情况下都是一个双代理系统，人们常常对这些模式如此着迷，以至于忘记了手头的问题要复杂得多。通过试图坚持这些原则，他们实际上最终得到了一个有缺陷的架构。

ng-click="collapsed = !collapsed"