AngularJS: Comprendre le modèle de conception

Grâce à une énorme quantité de précieuses sources, j'ai quelques recommandations générales pour la mise en œuvre de composants dans les applications AngularJS:

Contrôleur de

• Contrôleur doit être juste un intercalaire entre le modèle et la vue. Essayer de le faire, mince que possible.

• Il est fortement recommandé de éviter la logique métier dans le contrôleur. Il doit être déplacé pour modèle.

• Contrôleur peut communiquer avec d'autres contrôleurs à l'aide de la méthode d'invocation (possible lorsque les enfants veut communiquer avec un parent) ou $émettent, $de diffusion et $sur méthodes. Émis et diffusé les messages doivent être maintenus à un minimum.

• Contrôleur doit soucient pas de la présentation ou de manipulation du DOM.

• Essayer de éviter imbriqués les contrôleurs de. Dans ce cas, contrôleur de parent est interprété comme modèle. Injecter des modèles de services partagés de la place.

• Portée dans le contrôleur doit être utilisé pour liaison modèle avec vue et
  
  l'encapsulation Modèle de Vue comme pour Modèle de Présentation motif de conception.

Portée

Traiter portée en lecture seule dans les modèles et en écriture seulement dans les contrôleurs. Le but de la portée est de se référer au modèle, de ne pas être le modèle.

Lors bidirectionnel de liaison (ng-model) assurez-vous de ne pas lier directement à la portée des propriétés.

Modèle

Modèle dans AngularJS est un singleton défini par service.

Modèle fournit un excellent moyen pour séparer les données et de les afficher.

Modèles sont les premiers candidats pour les tests unitaires, comme ils ont généralement exactement une dépendance (une forme de manifestation de l'émetteur, dans le cas de la $rootScope) et contiennent très testable domaine de la logique.

• Modèle doit être considéré comme une mise en place de l'unité en question.
  Elle est basée sur une seule responsabilité de principe. L'unité est une instance qui est responsable de son propre champ d'application de la logique que peut représenter la seule entité dans le monde réel et le décrire dans le monde de programmation en termes de de données et de l'état.

• Modèle doit encapsuler les données de votre application et de fournir un API
  pour accéder et manipuler des données.

• Modèle devrait être portable de sorte qu'il peut facilement être transporté sur similaires
  application.

• Par l'isolement de l'unité logique dans votre modèle, vous ont rendu plus facile
  les localiser, de les mettre à jour et conserver.

• Modèle peut utiliser des méthodes plus générales sur les modèles globaux qui sont communes
  pour l'ensemble de l'application.

• Essayez d'éviter de composition d'autres modèles dans votre modèle à l'aide de l'injection de dépendance si elle n'est pas vraiment dépendant de la diminution de composants de couplage et de l'unité de multiplication testabilité et convivialité.

• Essayez d'éviter d'utiliser des écouteurs d'événement dans les modèles. Il les rend plus difficiles à tester et généralement tue des modèles en termes de la seule responsabilité de principe.

Mise En Œuvre Du Modèle

Comme modèle doit encapsuler la logique en termes de données et de l'état, il devrait l'architecture de restreindre l'accès à ses membres ainsi nous pouvons garantir le couplage lâche.

La manière de le faire en application AngularJS est de la définir à l'aide de usine type de service. Cela va nous permettre de définir des propriétés privées et des méthodes très facile et aussi de retour publiquement accessibles dans le seul endroit qui le rendra vraiment lisible pour le développeur.

Un exemple:

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

La création de nouvelles instances

Essayez d'éviter d'avoir une usine qui renvoie une nouvelle mesure de fonction comme cela commence à décomposer l'injection de dépendance et de la bibliothèque va se comporter maladroitement, en particulier pour les tiers.

Une meilleure façon d'accomplir la même chose est d'utiliser de l'usine comme une API pour retourner une collection d'objets avec des méthodes getter et setter attaché à eux.

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

Modèle Global

En général, essayez d'éviter de telles situations et la conception de vos modèles correctement donc il peut être injecté dans le contrôleur et utilisés dans votre point de vue.

Dans le cas particulier de certaines méthodes nécessitent l'accessibilité globale à l'intérieur de l'application.
Pour la rendre possible, vous pouvez définir la " commune propriété $rootScope et le lier à commonModel lors de l'application de bootstrap:

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

Toutes vos méthodes globales vivent à moins de ‘commune la propriété. C'est une sorte de espace de noms.

Mais ne définit pas de méthodes directement dans votre $rootScope. Cela peut conduire à un comportement inattendu lorsqu'il est utilisé avec ngModel la directive au sein de votre portée de vue, généralement jonchent votre portée et conduit à la portée des méthodes de questions primordiales.

Ressources

De ressources vous permet d'interagir avec différents sources de données.

Devraient être mises en œuvre à l'aide de seule responsabilité de principe.

Dans le cas particulier, il est un réutilisables proxy HTTP/JSON points de terminaison.

Ressources sont injectées dans les modèles et assurer la possibilité d'envoyer et de récupérer des données.

De ressources de mise en œuvre

Une usine qui crée un objet de ressource qui vous permet d'interagir avec RESTful côté serveur des sources de données.

Le retour de l'objet de la ressource a des méthodes d'action qui fournissent de haut niveau des comportements, sans la nécessité d'interagir avec le faible niveau de $service http.

Services

À la fois modèle et des ressources sont des services.

Services non liés, faiblement couplé unités de fonctionnalités qui sont autonomes.

Services sont une fonctionnalité qui Angulaire apporte à côté client applications web côté serveur, où les services ont été couramment utilisés pendant une longue période.

Services Angulaire applications sont substituables les objets qui sont fixés ensemble à l'aide de l'injection de dépendance.

Angulaire est livré avec différents types de services. Chacun avec son propre cas d'utilisation. Veuillez lire Comprendre Les Types De Services De pour plus de détails.

Essayez de tenir compte de les grands principes de l'architecture de services dans votre application.

En général selon Services Web Glossaire:

Un service est un résumé de la ressource qui représente une capacité de
de l'exécution de tâches qui forment un ensemble cohérent de fonctionnalités à partir du point de
vue de fournisseurs de entités et les demandeurs d'entités. Pour être utilisé, un
le service doit être réalisé par un fournisseur de béton de l'agent.

Côté Client, structure

En général partie client de l'application est découpée en modules. Chaque module doit être testable comme une unité.

Essayer de définir les modules en fonction de fonction/fonctionnalités ou vue, non pas par type.
Voir Misko présentation pour plus de détails.

Des composants du Module peut être classiquement regroupés par types, tels que les contrôleurs, les modèles, les vues, les filtres, directives, etc.

Mais le module en lui-même reste réutilisables, transférables et testable.

Il est aussi beaucoup plus facile pour les développeurs de trouver certaines parties de code et de toutes ses dépendances.

Veuillez vous référer à Code de l'Organisation dans les Grandes AngularJS et des Applications JavaScript pour plus de détails.

Un exemple de dossiers structurants:

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

Bon exemple de l'angulaire de l'application de structuration est mis en œuvre par angulaires-app - https://github.com/angular-app/angular-app/tree/master/client/src

Ceci est également considéré par l'application moderne générateurs - https://github.com/yeoman/generator-angular/issues/109

Un problème mineur en comparaison des grands conseils dans l'Art de la réponse, mais en termes de lisibilité du code, j'ai trouvé préférable de définir l'API complètement à l'intérieur de la return objet, afin de minimiser les va-et-vient dans le code wheverer variables sont définies:

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

Si le return objet devient à la recherche "trop de monde", ce qui est un signe que le Service est d'en faire trop.

À être croustillante à propos de la question, Angulaire utilise différents modèles de conception que nous avons déjà rencontrées dans notre programmation régulière.
1) Quand on enregistre nos contrôleurs ou des directives, l'usine, les services, etc à l'égard de notre module. Ici, c'est de cacher les données à partir de l'espace mondial. Qui est motif de Module.
2) Lorsque angulaire utilise son sale de vérifier pour la comparaison de la portée des variables, ici, il utilise Pattern observer.
3) le parent de l'enfant étendues dans nos contrôleurs utilise Prototypes modèle.
4) Dans le cas de l'injection les services qu'il utilise Modèle de Fabrique.

L'ensemble, il utilise différents connu des modèles de conception pour résoudre les problèmes.