Dzięki ogromnej ilości cennych źródeł mam kilka ogólnych zaleceń dotyczących implementacji komponentów w aplikacjach AngularJS:

Controller

• Kontroler powinien być tylko międzywarstwą pomiędzy modelem a widokiem. Postaraj się, aby był jak cienki , Jak to możliwe.

• Zaleca się, aby unikać logiki biznesowej w kontrolerze. Należy go przenieść do modelu.

• Kontroler może komunikować się z innymi Kontrolery wykorzystujące wywołanie metody (możliwe, gdy dzieci chcą komunikować się z rodzicem) lub $emit, $broadcast i $on metody. Emitowane i nadawane komunikaty powinny być ograniczone do minimum.

• Kontroler powinien nie przejmować się prezentacją ani manipulacją DOM.

• Spróbuj unikać zagnieżdżonych kontrolerów. W tym przypadku kontroler nadrzędny jest interpretowany jako model. Inject models as shared services zamiast tego.

• Zakres w kontrolerze powinien być używany do wiązania modelu z widokiem i
  enkapsulacja model widoku Jak dla Model prezentacji wzór projektowy.

Zakres

Traktuj scope jako Tylko do odczytu w szablonach i Tylko do zapisu w kontrolerach. Celem zakresu jest odniesienie się do modelu, a nie do modelu.

Wykonując Wiązanie dwukierunkowe (model ng) upewnij się, że nie wiąże się bezpośrednio z właściwościami zakresu.

Model

Model w AngularJS tosingleton zdefiniowany przezserwis .

Model zapewnia doskonały sposób na oddzielenie danych i wyświetlanie.

Modele są głównymi kandydatami do testów jednostkowych, ponieważ zazwyczaj mają dokładnie jedną zależność (jakąś formę emitera zdarzeń, w powszechnym przypadku $rootScope ) i zawierają wysoce testowalną logikę domeny.

• Model powinien być rozpatrywane jako realizacja danej jednostki. Opiera się ona na zasadzie jednej odpowiedzialności. Jednostka jest instancją odpowiedzialną za własny zakres logiki, która może reprezentować pojedynczą jednostkę w świecie rzeczywistym i opisywać ją w świecie programowania w kategoriach danych i stanu .

• Model powinien zawierać dane aplikacji i dostarczać API aby uzyskać dostęp i manipulować tymi danymi.

• Model powinien być przenośny więc można go łatwo przetransportować do podobnych podanie.

• Izolując logikę jednostki w swoim modelu ułatwiłeś zlokalizuj, Aktualizuj i utrzymuj.

• Model może używać metod bardziej ogólnych modeli globalnych, które są powszechne dla całej aplikacji.

• Staraj się unikać komponowania innych modeli do swojego modelu za pomocą iniekcji zależności, Jeśli nie jest to tak naprawdę zależne od zmniejszenia sprzężenia składników i zwiększenia jednostki testowalność i usability .

• Staraj się unikać używania słuchaczy zdarzeń w modelach. Utrudnia to ich testowanie i ogólnie zabija modele pod względem zasady jednej odpowiedzialności.

Implementacja Modelu

Ponieważ model powinien zawierać pewną logikę pod względem danych i stanu, powinien architektonicznie ograniczać dostęp do swoich członków, dzięki czemu możemy zagwarantować luźne sprzężenie.

Sposobem na to w aplikacji AngularJS jest zdefiniowanie go za pomocą fabryka rodzaj usługi. Pozwoli nam to bardzo łatwo definiować prywatne właściwości i metody, a także zwracać publicznie dostępne w jednym miejscu, co sprawi, że będzie naprawdę czytelne dla programistów.

Przykład :

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

Tworzenie nowych instancji

Staraj się unikać posiadania fabryki, która zwraca nową funkcję able, ponieważ zaczyna się to rozkładać Wtrysk zależności i biblioteka będzie zachowywać się niezręcznie, szczególnie dla osób trzecich.

A lepszym sposobem na osiągnięcie tego samego jest użycie factory jako API do zwrócenia kolekcji obiektów z dołączonymi do nich metodami getter i 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
    // ...
  };
});

Model Globalny

Ogólnie staraj się unikać takich sytuacji i odpowiednio Zaprojektuj swoje modele, aby mogły być wtryskiwane do kontrolera i używane według Ciebie.

W szczególności niektóre metody wymagają globalnej dostępności w aplikacji. Aby było to możliwe można zdefiniować właściwość' common ' w $rootScope i powiązać go z commonModel podczas uruchamiania aplikacji:

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

Wszystkie Twoje globalne metody będą żyć w ' common' właściwość. Jest to rodzaj przestrzeni nazw.

Ale nie Definiuj żadnych metod bezpośrednio w $rootScope. Może to prowadzić do nieoczekiwanego zachowania W przypadku użycia z dyrektywą ngModel w Twoim zakresie widzenia, zazwyczaj zaśmiecając twój zakres i doprowadzając do nadpisania metod zakresu problemy.

Zasób

Zasób pozwala na interakcję z różnymi źródłami danych .

Powinny być realizowane przy użyciu Zasady pojedynczej odpowiedzialności .

W szczególnym przypadku jest to wielokrotnego użytku proxy do punktów końcowych HTTP/JSON.

Zasoby są wtryskiwane w modelach i zapewniają możliwość wysyłania / pobierania danych.

Implementacja zasobów

Fabryka, która tworzy obiekt zasobu, który pozwala na interakcję z RESTful źródła danych po stronie serwera.

Zwracany obiekt zasobu posiada metody akcji, które zapewniają zachowania wysokiego poziomu bez konieczności interakcji z usługą $http niskiego poziomu.

Usługi

Zarówno model jak i zasób to usługi .

Usługi są niezwiązane, luźno powiązane jednostki funkcjonalności, które są autonomiczne.

Usługi to funkcja, którą Angular przenosi do aplikacji internetowych po stronie klienta od strony serwera, gdzie usługi są powszechnie używane przez długi czas.

Usługi w aplikacjach Angular są obiektami zastępowalnymi, które są połączone ze sobą za pomocą iniekcji zależności.

Angular oferuje różne rodzaje usług. Każdy z nich ma swoje własne przypadki użycia. Proszę przeczytać zrozumienie typów usług aby uzyskać szczegółowe informacje.

Spróbuj rozważyć główne zasady architektury usług w swojej aplikacji.

Ogólnie według serwisów internetowych Słowniczek :

Usługa jest abstrakcyjnym zasobem, który reprezentuje zdolność wykonywanie zadań, które tworzą spójną funkcjonalność z punktu widok podmiotów oferujących i podmiotów zamawiających. Do wykorzystania, a usługa musi być realizowana przez konkretnego agenta dostawcy.

Struktura po stronie Klienta

Ogólnie strona klienta aplikacji jest podzielona na moduły . Każdy moduł powinien być testowalny jako unit.

Spróbuj zdefiniować Moduły w zależności od funkcji/funkcjonalności lub widoku , a nie według typu. Zobacz prezentację Misko po szczegóły.

Komponenty modułu mogą być konwencjonalnie grupowane według typów, takich jak kontrolery, modele, widoki, filtry, dyrektywy itp.

Ale sam moduł pozostaje wielokrotnego użytku, zbywalne i testowalne.

Jest również znacznie łatwiej dla programistów znaleźć niektóre części kodu i wszystkie jego zależności.

Proszę zapoznać się z Organizacja kodu w dużych AngularJS i aplikacji JavaScript aby uzyskać szczegóły.

Przykład struktury folderów :

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

Dobry przykład struktury aplikacji kątowej jest zaimplementowany przez angular-app - https://github.com/angular-app/angular-app/tree/master/client/src

Jest to również rozważane przez nowoczesne Generatory aplikacji - https://github.com/yeoman/generator-angular/issues/109