How to structure angularJS models for large and serviced applications?

Question

In my foray into AngularJS, I was a little embarrassed. The main reason for this is that I really did not quite understand what the model part of all this is. I mean, its MVC framework, so it should have models, right? So, I read a little about this. I tried reading this bit of documentation here .

I realized from this that the model aspect of the controller is that what was actually inside the $scope dictionary. Well, and that didn’t bother me until I read the evil trout blog post , one of the discourse creators.

What he was trying to overcome was that Angular did not have the right modeling scheme. I tried to find answers on SO, and I came across this . It was well read, but it really did not give me concrete examples of how to structure models in AngularJS.

I felt that this has really been lacking since then, I'm used to developing django, and clear models are useful. In emberjs, there seems to be a way to make models that inherit from the Ember class. Also, after reading the evil trout blog blog, I understand the potential pitfalls of having all the variables associated with the scope, and many of them are primitives, not objects.

So what is the best way to structure your model in AngularJS, so you may have supported code in the future. The main reason I stick with Angular is that it is very easy to write, but I'm afraid that it might turn out to be something like php, where functions are often crowded out for the sake of simplicity.

I hope I was able to pose my question, if not then, please feel free to leave a comment telling me how I can improve.

Answer 1

What to remember about models

They are a piece of data ...

• This piece may come from an API, a static file, be explicitly declared.
• It can be updated with events in your application.

There can be many or one ...

• The model does not have to be an all-encompassing object. If you see the possibility of abstracting small models from one model, you will find modular code. Deploying child services into your parent ensures separation of problems and reuse.

A good example here is the thought of a service that uses two APIs to create a single model. You could 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 these API calls in another project? Are the components that make up my only service truly best represented as my 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 regardless of things . This is great news, because the next project you are working on does not need thing1 , but it definitely needs thing2 . If nothing else, modular services (or any code in general) will give you a framework for your application that helps you identify things as components, not blobs.

Answer 2

We have been using Angular for some time, and we have come to an agreement that helps us control pollution control.

We define the max 2 properties in the $scope variable in each controller. viewModel and model . viewModel is an object that helps us achieve simple binding to a model and a model object, which is the data related to the view for CRUD operations.

We follow this convention in the main view ( ng-view ), the subview (the view created using ng-include ), the directive (if we create an isolated area).

Shameless plugin . I wrote a blog post detailing it just a few days ago :)