How to structure angularJS models for large and maintainable applications?

Question

In my foray into AngularJS, I've been a little confused. The main reason for this, is because I never really quite understood, what the model part of the whole thing was. I mean, its a MVC framework, so it had to have models, correct? So, I did a little bit of reading on the matter. I tried reading this bit of documentation, here.

What I understood from that was, that the model aspect of the controller, what in fact what was inside the $scope dictionary. Fine, and this did not bother me, until I read a blog post by evil-trout, one of the makers of discourse.

What he was trying to get by, was that Angular did not have a proper modelling scheme. I tried looking into SO for answers, and I bumped into this. This was a good read, but really did not give me concrete examples of how to structure models in AngularJS.

I've felt that this was indeed lacking since, I'm used to django development, and having clear models is helpful. In emberjs, there seems to be a way to make models, that inherit from an Ember class. Also, after reading evil-trout's blog post, I understand the potential pitfalls of having all variables attached to the scope, and many of them being primitives, and not objects.

So, what is the best way to structure a model in AngularJS, such that you can have maintainable code in the future. The main reason I stick with angular is because it is wonderfully simple to write, but I fear that it might end up being something like php, where functionality has often been supplanted for the sake of simplicity.

I hope I've been able to make my question clear, if not then please feel free to leave a comment, telling me how I can improve.

Answer 1

Things to remember about models

They represent a chunk of data...

• That chunk can come from an API, a static file, be explicitly declared.
• It can be updated by events in your app.

They can be many or one...

• A model does not have to be an all encompassing object. If you see potential for abstracting smaller models from a single model, you have discovered modular code. Injecting child services into your parent ensures a separation of concerns and re-usability.

A good example here is think about a service that consumes two API's to build a single model. You could certainly build it like this:

angular.module('things', [])
.factory('Things', function($http) {
    var _things = {};
    _things.getThing1 = function(){return $http.get('http://ONE.com/1')};
    _things.getThing2 = function(){return $http.get('http://TWO.com/2')};
    return _things;
};

But what if you want to use those API calls in another project? Are the components that make up my single service really best represented as their own services?

angular.module('thing1', [])
.factory('T1', function($http) {
    var _thing1 = {};
    _thing1.getThing1 = function(){return $http.get('http://ONE.com/1')};
    return _thing1;
};

angular.module('thing2', [])
.factory('T2', function($http) {
    var _thing2 = {};
    _thing2.getThing2 = function(){return $http.get('http://TWO.com/2')};
    return _thing2;
};

angular.module('things', ['thing1','thing2'])
.factory('Things', function(T1,T2) {
    var _things = {};
    _things.getThing1 = T1.getThing1();
    _things.getThing2 = T2.getThing2();
    return _things;
};

Now you can use thing1 or thing2 independent of things. Which is great news, because the next project you are working on doesn't need thing1 but definitely needs thing2. If nothing else, modular services (or any code in general) will give you structure to your app that will help you identify things as components rather than blobs.

Answer 2

We have been using Angular for some time now and we have come up with a convention that helps us in keeping scope pollution under control.

We define at max 2 properties on the the $scope variable in every controller. viewModel and model. The viewModel being a object which helps us in achieving easy model binding and the model object which is the data pertaining to the view for CRUD operations.

We follow this convention across main view (ng-view),sub-view (view created with ng-include), directives (if we create isolated scope).

Shameless plug: I wrote a blog post detailing this just few days back :)