AngularJS: Как структурировать контроллеры и фабрики/службы с помощью богатой иерархической объектной модели?

Ответ 1

После того, как MUCH переделывает и пытается использовать разные подходы, мое окончательное решение заключается в том, что вы не должны сохранять свою богатую объектную модель по представлениям.

Я держу объектную модель супер-тощей и загружаю только то, что мне нужно для каждого вида. Есть данные высокого уровня, которые я поддерживаю (данные пользователя, такие как имя, идентификатор, электронная почта и т.д., А также данные организации, например, в какой организации они вошли), но все остальное загружается для текущего представления.

С помощью этого тощего подхода, как бы выглядел мой factory:

app.factory('InboxFactory', function InboxFactory ($location, NotificationFactory) {

factory.messages = [];

factory.openMessage = function (message) {
  $location.search('id', message.id).path('/message');
};

factory.deleteMessage = function (message) {
  $http.post('/message/delete', message)
  .success(function (data) {
    NotificationFactory.showSuccess();
    return data;
  })
  .error(function () {
    NotificationFactory.showError();
    return null;
  });
};

factory.getMessages = function (userId) {
  return $http.get('/messages/user/id/'+userId)
  .success(function (data) {
    return data;
  })
  .error(function () {
    NotificationFactory.showError();
    return null;
  });
};

return factory;

});

И контроллер:

app.controller('InboxCtrl', function InboxCtrl (InboxFactory) {

  var vm = this;

  vm.messages = {};

  vm.openMessage = function (message) {
    InboxFactory.openMessage(message);
  };

  vm.deleteMessage = function (message) {
    InboxFactory.deleteMessage(message);
  };

  InboxFactory
    .getMessages(userId) //you can get the userId from anywhere you want.
    .then(function (data) {
      vm.messages = data;
  });

});

Преимущества:

• упрощенная прикладная логика
• худой и средний, легкий (я загружаю только то, что мне нужно для текущего состояния)
• меньше использования памяти, что обеспечивает общую производительность, особенно на мобильных устройствах.

Ответ 2

Вы можете использовать богатую объектную модель, но для объектов, которые не являются топ-уровнями, их фабрики должны выставлять api для создания новых экземпляров, а не для использования в качестве одиночных. Это несколько противоречит дизайну многих приложений, которые вы видите в наши дни, которые более функциональны, чем объектно-ориентированные. Я не комментирую плюсы и минусы любого подхода, и я не думаю, что Angular заставляет вас принять тот или иной.

Ваш пример, переработанный, в псевдокоде:

app.controller('InboxCtrl', function InboxCtrl (InboxFactory) {

   var inbox = InboxFactory.createInbox();

   $scope.getMessages = function(){
      inbox.getMessages()
           .then(...)

   $scope.deleteMessages = function(){
      inbox.deleteMessages()
           .then(...)

});

Ответ 3

Ваша ситуация становится намного проще, если вы примете подход на основе маршрута (a la ngRoute или что-то подобное). Рассмотрим эту альтернативу - предупреждение непроверенного кода:

app.config(function($routeProvider) {
  $routeProvider
    .when('/inbox/:inboxId',
      templateUrl: 'views/inbox.html',
      controller: 'InboxCtrl',
      controllerAs: 'inbox',
      resolve: {
        inboxMessages: function(InboxFactory) {
          // Use use :inboxId route param if you need to work with multiple
          // inboxes. Taking some libery here, we'll assuming
          // `InboxFactory.getMessages()` returns a promise that will resolve to
          // an array of messages;
          return InboxFactory.getMessages();
        }
      }
    // ... other routes
    .otherwise: {
      // ...
    };
});

app.controller('InboxCtrl', function InboxCtrl (InboxFactory, inboxMessages) {
  var vm = this;
  vm.messages = inboxMessages;
  vm.openMessage = InboxFactory.openMessage;
  vm.deleteMessage = InboxFactory.deleteMessage;
});

Посмотрите, насколько тонкий контроллер сейчас! Конечно, я использовал несколько более компактный синтаксис в нескольких местах, но это подчеркивает, как наш контроллер действительно просто склеивает вещи.

Мы можем еще больше упростить процесс, избавившись от InboxFactory.messages, когда мы его фактически будем использовать? Нам гарантируется, что он будет заполнен после того, как InboxFactory.getMessages будет разрешен, так что пусть это обещание будет разрешено самим сообщениям.

Сохранение данных в одиночных точках таким образом может быть самым простым решением в некоторых случаях, но это затрудняет жизнь, когда эти данные должны быть получены на лету. Вам будет лучше отказаться от API и фабрик (как предлагает AlexMA), вытаскивая необходимые данные всякий раз, когда маршрут изменяется (например, пользователь хочет посмотреть на другой почтовый ящик) и вводить эти данные непосредственно в соответствующий контроллер.

Другим преимуществом этой формы является получение наших данных в момент создания экземпляра контроллера. Нам не нужно жонглировать асинхронными состояниями или беспокоиться о том, чтобы вводить много кода в обратные вызовы. В качестве следствия мы обнаруживаем ошибки загрузки данных перед отображением нового представления "Входящие", и пользователь не застревает в полуиспеченном состоянии.

В дополнение к точке вашего вопроса, хотя обратите внимание, что бремя знания того, как ваша богатая модельная модель сочетается, уже не проблема контроллера. Он просто получает некоторые данные и предоставляет кучу методов для представления.