AngularJS : How should controllers and factories/services be structured with a rich, 分层对象模型？

Question

我读了这两篇很棒的文章:

The state of angularjs controllers乔纳森·克里默

和

Rethinking AngularJS Controllers托德·莫托

在这些文章中，作者讨论了使用 Controller (使它们成为 View 和模型之间的桥梁)和工厂/服务(业务逻辑应该真正存在的地方)的正确方法。

这是很好的信息，我很高兴开始在我的一个项目中重构 Controller ，但我很快发现，如果你有一个丰富的对象模型，文章中显示的结构就会崩溃。

以下是“重新思考 Angularjs Controller ”中设置的回顾:

这是 Controller :

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

    var vm = this;

    vm.messages = InboxFactory.messages;

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

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

    InboxFactory
      .getMessages()
      .then(function () {
      vm.messages = InboxFactory.messages;
    });

});

这是工厂:

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) {
      factory.messages.splice(index, 1);
      NotificationFactory.showSuccess();
    })
    .error(function () {
      NotificationFactory.showError();
    });
  };

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

  return factory;

});

这很棒，因为 providers (工厂)是单例的，数据跨 View 维护，无需从 API 重新加载即可访问。

这工作得很好 如果 messages是顶级对象 .但如果他们不是，会发生什么？如果这是一个用于浏览其他用户收件箱的应用程序怎么办？也许您是管理员，并且您希望能够管理和浏览任何用户的收件箱。也许您需要同时加载多个用户的收件箱。这是如何运作的？问题是收件箱消息存储在服务中，即 InboxFactory.messages .

如果层次结构是这样的:

                           Organization
                                |
              __________________|____________________
             |                  |                    |
         Accounting       Human Resources            IT
             |                  |                    |
     ________|_______      _____|______        ______|________
    |        |       |    |     |      |      |      |        |
   John     Mike    Sue  Tom   Joe    Brad   May    Judy     Jill
    |        |       |    |     |       |     |      |        |
   Inbox    Inbox  Inbox Inbox Inbox  Inbox Inbox  Inbox    Inbox

现在 messages在层次结构中很深的几个层次，它们本身没有任何意义。工厂不能存储消息， InboxFactory.messages因为您必须一次检索多个用户的消息。

现在您将拥有一个 OrganizationFactory、一个 DepartmentFactory、一个 UserFactory 和一个 InboxFactory。检索“消息”必须在 user 的上下文中，谁在 department 的上下文中，这是在 organization 的上下文中.数据应该如何以及在哪里存储？应该如何取回？

那么这应该如何解决呢？ Controller 、工厂/服务和富对象模型应该如何构建？

在我思考的这一点上，我倾向于保持精简而不是拥有丰富的对象模型。只需将对象存储在注入(inject) Controller 的 $scope 上，如果您导航到新 View ，请从 API 重新加载。如果你 需要一些数据在 View 中持久存在，您可以使用服务或工厂来构建桥梁，但它不应该是您的方式 最多事物。

其他人是如何解决这个问题的？这有什么模式吗？

Answer 1

您可以使用丰富的对象模型，但对于不是顶级的对象，它们的工厂应该公开一个用于创建新实例的 api，而不是用作单例。这与你现在看到的许多应用程序的设计有些相反，这些应用程序比面向对象更实用——我没有评论这两种方法的优缺点，我不认为 Angular 会强制你采用非此即彼。

您的示例，重新设计，伪代码:

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

   var inbox = InboxFactory.createInbox();

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

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

});