Gracias a una gran cantidad de fuentes valiosas, tengo algunas recomendaciones generales para implementar componentes en aplicaciones AngularJS:

Controlador

• El controlador debe ser solo una capa intermedia entre el modelo y la vista. Intenta que sea lo más delgado posible.

• Es muy recomendable que evite la lógica de negocios en el controlador. Debe ser movido al modelo.

• El Controlador puede comunicarse con otros controladores que usan invocación de métodos (posible cuando los hijos quieren comunicarse con el padre) o emit emit, $broadcast and on on methods. Los mensajes emitidos y emitidos deben reducirse al mínimo.

• Al controlador no le importa la presentación o la manipulación del DOM.

• Intente evitar los controladores anidados. En este caso, el controlador padre se interpreta como modelo. Inyectar modelos como servicios compartidos en su lugar.

• Scope en el controlador debe usarse para binding model with view y
  encapsular Ver Modelocomo para Modelo de presentación patrón de diseño.

Ámbito de aplicación

Trate el ámbito como de solo lectura en las plantillasy de solo escritura en los controladores. El propósito del alcance es referirse al modelo, no ser el modelo.

Al hacer encuadernación bidireccional (ng-model) asegúrese de que no se vincule directamente a las propiedades del ámbito.

Modelo

El modelo en AngularJS es un singleton definido por service.

El modelo proporciona una excelente manera de separar los datos y la visualización.

Los modelos son candidatos principales para pruebas unitarias, ya que típicamente tienen exactamente una dependencia (alguna forma de emisor de eventos, en el caso común el ro rootScope) y contienen lógica de dominio altamente comprobable.

• Modelo debe ser considerado como una implementación de unidad particular. Se basa en el principio de responsabilidad única. Unit es una instancia que es responsable de su propio alcance de lógica relacionada que puede representar una sola entidad en el mundo real y describirla en el mundo de programación en términos de datos y estado.

• El modelo debe encapsular los datos de su aplicación y proporcionar una API para acceder y manipular esos datos.

• El modelo debe ser portable so se puede transportar fácilmente a similares aplicación.

• Al aislar la lógica de la unidad en su modelo, ha hecho que sea más fácil localizar, actualizar y mantener.

• Modelo puede utilizar métodos de modelos globales más generales que son comunes para toda la aplicación.

• Trate de evitar la composición de otros modelos en su modelo utilizando la inyección de dependencias si no es realmente dependiente para disminuir el acoplamiento de componentes y aumentar la unidad probabilidad y usabilidad.

• Trate de evitar el uso de detectores de eventos en los modelos. Hace que sean más difíciles de probar y generalmente mata modelos en términos de principio de responsabilidad única.

Aplicación del modelo

Como el modelo debe encapsular alguna lógica en términos de datos y estado, debe restringir arquitectónicamente el acceso a sus miembros, por lo que podemos garantizar un acoplamiento suelto.

La forma de hacerlo en la aplicación AngularJS es definirlo usando tipo de servicio de fábrica . Esto nos permitirá definir propiedades privadas y métodos muy fáciles y también devolver los públicamente accesibles en un solo lugar que lo hará realmente legible para el desarrollador.

Un ejemplo:

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
  };
});

Creando nuevas instancias

Trate de evitar tener una fábrica que devuelve una nueva función able ya que esto comienza a descomponer la inyección de dependencias y la biblioteca se comportará de manera incómoda, especialmente para terceros.

A la mejor manera de lograr lo mismo es usar la fábrica como una API para devolver una colección de objetos con los métodos getter y setter adjuntos a ellos.

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
    // ...
  };
});

Modelo Global

En general, trate de evitar este tipo de situaciones y diseñar sus modelos correctamente por lo que se puede inyectar en el controlador y se utiliza en su vista.

En caso particular, algunos métodos requieren accesibilidad global dentro de la aplicación. Para hacerlo posible, puede definir la propiedad 'common ' en ro rootScope y enlazarlo a commonModel durante el bootstrap de la aplicación:

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

Todos tus métodos globales vivirán dentro de la propiedad ' common'. Esto es una especie de espacio de nombres .

Pero no defina ningún método directamente en su ro rootScope. Esto puede llevar a un comportamiento inesperado cuando se usa con la directiva ngModel dentro del alcance de la vista, generalmente ensuciando su alcance y conduce a la anulación de los métodos de alcance cuestión.

Recurso

Resource le permite interactuar con diferentes fuentes de datos .

Debe aplicarse utilizando el principio de responsabilidad única.

En particular, se trata de un proxy reutilizable para endpoints HTTP/JSON.

Los recursos se inyectan en los modelos y proporcionan la posibilidad de enviar/recuperar datos.

Implementación de recursos

Una fábrica que crea un objeto de recurso que le permite interactuar con Fuentes de datos RESTful del lado del servidor.

El objeto de recurso devuelto tiene métodos de acción que proporcionan comportamientos de alto nivel sin la necesidad de interactuar con el servicio http http de bajo nivel.

Servicios

Tanto el modelo como el recurso son servicios .

Los servicios no están asociados, unidades de funcionalidad poco acopladas que son autónomas.

Los servicios son una característica que Angular trae a las aplicaciones web del lado del cliente desde el lado del servidor, donde los servicios se han utilizado comúnmente durante mucho tiempo.

Los servicios de las aplicaciones de Angular son objetos sustituibles que se conectan mediante inyección de dependencias.

Angular viene con diferentes tipos de servicios. Cada uno con sus propios casos de uso. Por favor lea Descripción de los tipos de servicio para más detalles.

Trate de considerar los principios principales de la arquitectura de servicios en su aplicación.

En general según Servicios Web Glosario:

Un servicio es un recurso abstracto que representa una capacidad de realizar tareas que forman una funcionalidad coherente desde el punto de vista de entidades proveedores y entidades solicitantes. Para ser utilizado, a el servicio debe ser realizado por un agente proveedor concreto.

Estructura del lado del cliente

En general, el lado del cliente de la aplicación se divide en módulos . Cada módulo debe ser comprobable como unidad.

Intente definir módulos dependiendo de característica/funcionalidad o vista, no por tipo. Véase La presentación de Misko para más detalles.

Los componentes del módulo pueden agruparse convencionalmente por tipos como controladores, modelos, vistas, filtros, directivas, etc.

Pero módulo en sí sigue siendo reutilizables, transferible y comprobable.

También es mucho más fácil para los desarrolladores encontrar algunas partes del código y todo sus dependencias.

Por favor refiérase a Organización de código en AngularJS Grandes y Aplicaciones JavaScript para más detalles.

Un ejemplo de estructuración de carpetas :

|-- 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

Un buen ejemplo de estructuración de aplicaciones angular es implementado por angular-app - https://github.com/angular-app/angular-app/tree/master/client/src

Esto también es considerado por los generadores de aplicaciones modernas - https://github.com/yeoman/generator-angular/issues/109