AngularJS : How should controllers and factories/services be structured with a rich, hierarchical object model?

Question

I read these two great articles:

The state of angularjs controllers by Jonathan Creamer

and

Rethinking AngularJS Controllers by Todd Motto

In these articles, the authors talk about the right way to use controllers (making them anemic bridges between the view and the model) and factories/services (where the business logic should really live).

This is great information, and I was really excited to start refactoring the controllers on one of my projects, but I quickly found that the structure shown in the articles breaks down if you have a rich object model.

Here's a recap of the setup from "Rethinking Angularjs Controllers":

Here's the 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;
    });

});

and here's the 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) {
      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;

});

This is great and because providers (the factory) are singletons, the data is maintained across views and can be accessed without having to reload it from the API.

This works just fine if messages are a top level object. But what happens if they aren't? What if this is an app for browsing the inboxes of other users? Maybe you're an administrator and you want to be able to manage and browse the inboxes of any user. Maybe you need multiple users' inboxes loaded at same time. How does this work? The problem is inbox messages are stored in the service, i.e. InboxFactory.messages.

What if the hierarchy is like this:

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

Now messages are several levels deep in the hierarchy, and have no meaning on their own. You can't store messages in the factory, InboxFactory.messages because you have to retrieve messages for several users at a time.

Now you will have an OrganizationFactory, a DepartmentFactory, a UserFactory, and an InboxFactory. Retrieving "messages" must be in the context of a user, who is in the context of a department, which is in the context of an organization. How and where should the data be stored? How should it be retreived?

So how should this be resolved? How should controllers, factories/services, and rich object models be structured?

At this point in my thinking, I'm leaning towards just keeping it lean and not having a rich object model. Just store the objects on the $scope injected into the controller, and if you navigate to a new view, reload from the API. If you need some data persisted across views, you can build that bridge with a service or factory, but it shouldn't be the way you do most things.

How have other's solved this? Are there any patterns out there for this?

Villasenor

Shouldn't this be a task for backend endpoint? So if you are logged in as Jonh GET /messages returns messages only for John and interface is different from the one that organization boss sees when he is logged in. – Woodborer

Answer 1

After MUCH tinkering and trying different approaches, my final decision is that you shouldn't persist your rich object model across views.

I keep the object model super lean and load just what I need for each view. There is high level data that I keep around (user information like name, id, email, etc. and organization data like which organization they are logged in with), but everything else gets loaded for the current view.

With this lean approach, here's what my factory would look like:

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;

});

And the controller:

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

});

The benefits so far are:

• simplified application logic
• lean and mean, lightweight (I only load just what I need for the current state)
• less memory usage, which translates to overall better performance, especially on mobile

Villasenor

Answer 2

You can use a rich object model, but for objects that are not top-level, their factories should expose an api for creating new instances rather than be used as singletons. This is is somewhat contrary to the design of many apps you see these days, which are more functional than object-oriented--I am not commenting on the pros and cons of either approach, and I don't think Angular forces you to adopt one or the other.

Your example, redesigned, in pseudocode:

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

   var inbox = InboxFactory.createInbox();

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

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

});

Loaning

Thanks AlexMa. That's what I am leaning towards. Doing it like that, would you advocate having the object graph stored somewhere persistently between views? Or would you rather advocate the graph recreated (as necessary) for each applicable view? I'm leaning towards the later to keep the app lean and lightweight. – Villasenor

I would agree; I try to avoid making the app state any more complex than it needs to be, as it creates side effects and is harder to test and change later. – Loaning

Answer 3

Your situation becomes much simpler if you adopt a route based approach (a la ngRoute or something similar). Consider this alternative - warning untested code:

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

Look how slim the controller is now! Granted I made use of some more compact syntax in a couple spots but this highlights how our controller really is just glueing things together.

We can further streamline things by getting rid of InboxFactory.messages, when would we actually use it? We're only guaranteed to have to have it be populated after InboxFactory.getMessages resolves, so let's just have this promise resolve to the messages themselves.

Storing data in singletons in this way may be the easiest solution in some cases but it makes life difficult when that data must be fetched on the fly. You're going to be best off leaning on APIs and factories (as AlexMA suggests), pulling down the necessary data whenever a route changes (e.g. the user wants to look at a different inbox) and injecting that data directly into the appropriate controller.

Another benefit of this form is we get to have our data in hand at the time the controller is instantiated. We don't have to juggle asynchronous states or worry about putting lots of code in callbacks. As a corollary, we get to catch data loading errors before displaying a new inbox view and the user doesn't get stuck in a half baked state.

Further to the point of your question though notice that the burden of knowing how your rich model structure fits together is no longer the controller's problem. It just gets some data and exposes a bunch of methods to the view.

Touchhole

angular ui router provides nested routes, and is very convenient for those use cases – Warford